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Preface 


This manual is one of a series that describes the purpose and use of the SPERRY 
Operating System/3 (OS/3) Integrated Communications Access Method (ICAM). It 
specifically describes the communications physical interface and how it is used to write 
user programs at the physical level. This manual is intended for the applications 
programmer experienced in data cornmunications and assembler programming. 


The physical interface requires the least amount of main storage; but, it also provides a 
minimum amount of support. To use this interface, you must have considerable 
knowledge of data communications, because your program must initialize the hardware, 
format all output messages using the appropriate protocol, perform any ,equired 


. translations, acknowledge and process all input messages, and perform all error 
_ detection and recovery procedures. In addition, the communications portion of your 


program must be written in basic assembly language, and your system must include the — 
OS/3 assembier. 


The information contained in this manual is presented as follows: 


'. @~ Section 1. Basic Concepts 


Describes the overall concepts and procedures in writing a user program that uses 
the physical interface of ICAM. Introduces the contro! packet (table) format 
(CPIOCP) and imperative macroinstruction (CCRCALL) necessary to interface your 
program with ICAM software. Also discusses how to generate an ICAM network 
for a communications physical interface and how to load it. 


w Section 2. Writing a User Program 
Describes how to request the network and lines, initialize the single line 
communications adapter (SLCA), perform the transmit/receive functions, and 
release the lines and network. 

w Section 3. Additional User Program Features 
Discusses additional useful functions available via the physical interface, such as 


reading the SLCA words and tables, reading the line link table, chaining, and 
gutomatic commands. 


ae 
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w Section 4. Single Line Communications Adapter Subsystem 


Describes the singie line communications adapter hardware subsystem and the 
software procedures necessary to initialize it. The description includes construction 
of the port control words, character detect tables, and character interpretation table 
required to support the communications lines and line disciplines necessary for 
remote devices. 


w Section 5. SLCA Table Initialization 


Describes the initialization parameters for an SLCA pertinent to specific SPERRY 
remote device handlers. This includes the control character detect tables, control 
character interpretation tables, and port control words for terminals supported by . 
SPERRY software. . 


a Appendix A. Control Tables 


Describes the control packet and line link table used to present the required 
information to the system software. The tables are described via the dummy 
contro! section (DSECT) labels for the necessary fields and field settings. 


As one of a series, this manual is designed to guide you in programming and using the 
OS/3 integrated communications access method. Depending on your need, you may 
wish to refer to the current version of one of the other ICAM manuals. Complete manual 
names, their ordering numbers, and a general description of their contents and use is as 
follows: - 


= Integrated Communications Access Method (ICAM) Concepts and Facilities, 
UP-9744 


Provides an overview of the facilities offered by ICAM including the hardware 
_ supported, the types of programs supported (assembler, COBOL, and RPG Il), and 
the services provided (polling, queueing, buffering, etc). , 


w ICAM Network Definition and Operations User Guide, UP-9745 


Describes how to define an ICAM network, submit it to the system generation 
procedure, and load and operate the resulting ICAM symbiont. Many sample 
network definitions are provided to make it easier to define your ICAM network. In _ 
addition, most of the required operational functions are described. These functions 
include loading ICAM, establishing a dynamic session from a_ terminal, 
communicating with ICAM, etc. 


m ICAM Standard MCP (STDMCP) Interfase User Guide, UP-8550 


The standard interface is a logical interface that provides a general communications 
capability with messace queueing and a message processing capability. 


This user guide provides all of the macroinstructions, programming requirements, 
and terminal information you need to interface with the standard interface. 
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You will need this user guide only if you are writing your own communications 
program. Programs that use the standard interface directly must be coded in basic 
assembly language (BAL), and your system must include the OS/3 assembler. 


m ICAM Direct Data Interface (DD!) User Guide, UP-8549 


The DDI! interface commonly supports ICAM utility programs and programs written 
in the RPG II language. If you are using an ICAM utility only, or if your program is 
written in RPG Il, you won't need this user guide because the utility programs and 
the RPG II compiler automatically convert any requests by your program to the 
proper instructions needed to work with this interface. 


The DDI interface also enables you to write your own specialized communications 
program to work with it. If you do this, you must take care of your own message 
buffering and queueing. If you write a program to interface directly with direct data 
interface, it must be written in basic assembly language. 

ws ICAM Utilities User Guide, UP-9748 
Describes the utilities provided by ICAM. These utilities: 


- Enable your processor to emulate a SPERRY 1004 Card Processor System, 
SPERRY’ DCT 2000 terminal, or IBM 2780 terminal 


- Provide a facility to enable you to submit batch jobs from a remote terminal 
-~ Provide the capability to produce printed reports from journal files 
- Supply the software to create a module that converts communications requests 
in your COBOL program to instructions recognizable by the ICAM standard 
_ interface — . | 

~— Describe how to run RPG Il under ICAM as a utility 
- Describe how to dump and list the contents of an SLCA 
- Help locate the cause of operational problems 

m= ICAM Message Processing Procedure Specification (MPPS) User Guide, UP-8946 
MPPS enables you to write message processing routines and include them in your 
ICAM network. This makes it possible for ICAM to analyze and process input 
messages before they are made available to your program, including the 
establishment of priority based on message content. Message processing routines 
can also be used to process output messages, including rerouting, if necessary, due 
to hardware and software error conditions. 
You do not need to include message processing routines in your network — they 


are totally optional; hence your need for this user guide depends on your 
requirements. 





UP-S746 SPERRY OS/3 Preface 4 
ICAM COMMUNICATIONS PHYSICAL INTERFACE (CPI) 





= !ICAM Programmer Reference, UP-9749 


This reference summarizes the information found in the other ICAM manuals. No 
introductory information or examples are given; however, it is a useful document 
when you are familiar with ICAM and you need a quick reference to 
macroinstructions, formats, and tables. 


= NTR Utility User Guide, UP-9502 


Describes how the System 80 can operate as a remote job entry/batch terminal to 
a SPERRY Series 1100 System via ICAM. 


The utility permits operation of reader, punch, and printer device-dependent files. It 
also supports user-own-code tasks to process device-independent files (e.g., tape, 
disk, paper tape). 


ry] Remote Terminal Processor (RTP) User Guide, UP-8990 
The remote terminal processor is a data communications program that permits your 
SPERRY System 80 processor to function as a remote job entry terminal to one or 


more IBM host processors. Using the SPERRY OS/3 integrated communications 
access method (ICAM) software, the remote terminal processor enables you to: 


send jobs to an IBM host; 





transmit and receive files on tape, punched cards, or diskette; 
— send messages to the central site; and 
- receive output data and console messages from the IBM host. 


‘Remote terminal processor operations are directed from the OS/3 system console. 
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1. Basic Concepts 


1.1. GENERAL 


Data communications — very simply stated — is the transmission of computer data via 
communications lines. These lines may be directly connected from one piece of 
equipment to another (dedicated) or they may operate across telephone transmission 
switching equipment (switched). 


Just as the ordinary telephone converts vibrations (voice) to electrical impulses, an 
attachment to the telephone, called a data set, converts data bits to electrical 
frequencies. The household telephone uses diaphragms and magnets to. oscillate at 


. audio frequencies and superimposes this signal on a carrier wave. The data set uses a 
t™modem to modulate or demodulate a data signal and superimposes it on a carrier wave. 


Data input/output equipment (I/O devices) may be connected to a communications line 
via a data set or they may be directly connected to the line. When these I/O devices 
terminate a communications line directly, they contain their own internal modem and are 
commonly known as terminals. There are a large number of I/O devices that can be 
used as terminals, such as printers, punches, magnetic and paper tapes, disks, and 
video display. terminals. The terminals themselves may have additional |/O equipment 
attached, such as tape cassette drives and diskettes. This type of equipment is 
designated as an auxiliary device. Out of this diversity of equipment, analysis will show 
that there are a number of functions common to all that can be woven together to form 
a common structure for data communications software. (See Figure 1—1.) The first of 
these functions is a line request. In software terms, this means that we must specify 
the kind of line it is that we want. This may include the mode of communication, such 
as batch or interactive, the line speed and the line type (switched versus dedicated, half 
duplex versus full duplex, automatic versus manual dial, etc). 


In the following paragraphs, we use a simple UNISCOPE display terminal protocol to 
show how data communications works. 
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MAIN 


CONSIDERATIONS 


IN OUR 


USER PROGRAM 


NEED 


Figure 1~—1. 





batch /interactive 
LINE REQUEST line speed (baud rate of modulation) 


line type (switched, dedicated, unattended} 
(half dupiex/full duplex) 
(automatic/manual dial) 
CONNECT/ immediate 
DISCONNECT at 1/O time 


(Any message traffic?) 


PROTOCOL (handshaking) 


(transiation, message format, 
envelope building, network/line conversion) 


- SPECIAL 


(terminal auxiliary devices) 
FUNCTIONS : 





RECOVERY {retry /notification) 
PROCEDURES 


ERROR 
HANDLING 





Common Structure for Data Communications Software 
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Once we have requested the specific type of line we require and a connection is made, 
we must determine how we can converse with the other end of the line. That is, we 
must have set up some common rules and formats that both ends of the line are aware 
of and agree on. We must both speak the same language and play the same game. 
‘Thus, we have line protocol (the rules) and message envelopes (the format). The 
protocol (Figure 1-2) determines the sequence or order in which our messages are sent 
and received and is commonly known in the trade as handshaking. The message 
envelope (Figure 1-3) contains a prefix and suffix to the message transmitted. This 
contains basic information about the message, such as what kind of message it is, 
where it is going, and what is to be done with it. 


TRAFFIC | 
roe ee | TEXT 1 
ACK | 
| TEXT 2 


NAK 













| | texr2 
ACK 
| 


Figure 1~2. Typical Exampie of Line Protocol 


Now that we have formulated a basic set of rules and structure, how do we get our 
message or conversation going? Well, in a telephone conversation, when we call 
someone, we generally say “‘Hello’’ to find out if anyone is there. The sare holds true 
for our data conversation — we must first send some kind of message to the effect: 
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Is anyone out there? 
Does anyone have a message for me? 
or 
I'm sending a message, is anyone awake? 


This type of message is called a poll. It expects some kind of reply or response, such 
as an acknowledgment: 


Yes, I'm here. 

| have a message for you and here it is. 
or 

I'm awake — go ahead. 


Normally, you would respond with a “‘yes, | am’’ by sending text. | would then respond 
with an acknowledgment message (ACK) that says: “‘Got your first text message — 
thank you — please send more.’’ You would then send your second text message. 


Suppose, however, that | did not receive your second text message correctly — 
something may have been garbied or did not make sense in the order of things. | would 
then return a negative acknowledgment (NAK) and you would transmit the second text 
message again. - 


Another case might be that you would send me a message and | would not respond. In 
this case, your program would have. to time out and retransmit until it received an 
acknowledgment. After a certain number of retries and failures, it would disconnect or 
send an EOT. . 


If you sent me all the messages. you had or | signed off on my end, an EOT message 
_ would perform the disconnect notice. 


Now, if I’m going to send a poll message and expect an acknowledgment (ACK) or 
some text, what would these messages really look like? Well, let's look at some 
specific formats. (See Figure 1-3 and Table 1—1.) First, if | am in synchronous 
operation, my prefix (header) must have at least two synchronous characters (SYNCs), 
which are provided by the the single line communications adapter (SLCA). 


If I'm in asynchronous operation, | don’t have to send these characters, because the 
transmission equipment itself includes a transmission characteristic with each message 
transmitted. 

















UP-9746 SPERRY OS/3 1-5 
ICAM COMMUNICATIONS PHYSICAL INTERFACE (CPI) 





My header would now have a start-of-header (SOH) character preceding a destination 
address that consists of a RID, SID; and DID. A RID specifies a remote installation 
identifier, a hexadecimal number representing an installation such as the O’Hare Airport 
or the World Trade Center. A SID specifies a particular terminal station identifier, a 
hexadecimal number representing a station such as visual display 14. A DID specifies a 
hexadecimal device address of a specific auxiliary device that may be connected to a 
specific terminal station. This device address may represent a printer, a diskette, a tape 
cassette, or other supporting auxiliary devices. 


crate) [svn see sn] sen] son [no [50 [er] ce] 

nex —of sv [svn] sro] sve] son ]o [oo [ous [acx]erx ace] 
vax —o{ sve svn]sva[ svn] son no [se [oo [our [nan erx ocd 
erate [se svn] smi] sva]son]no [so [om Jenalem occ] 
vexr—ef svn svn] svn] svn] son] 0 [0 [oo [sr rext (Fx) ec] 


Figure 1-3. Typical Communications Message Envelopes 


Table 1~1. Control Character Description (Part 1 of 2) 


Acknowledgmem - An affirmative reply response used to positively acknowledge 
receipt of a message. indicates that line conditions and status of message are 


. Block check character - A character added at the end of a message or transmission 
biock to facilitate error detection. _ 


Device identifier ~ DID characters specify an auxiliary device. The DID is not a 
function of the device type but of the station configuration. 


Data link escape - A communications control character that will change the meaning 
of a limited number of contiguously following characters. It is used exclusively to 
provide supplementary controis in data cormmunications networks. 


Enquiry - A communications controller character used in data communications 
systems as a request for a response from a remote station. ft may be used as a 
“Who are you?” (WRU) to obtain identification, or may be used to obtain station 
status, or both. (ENQ is the basic character for the status poll.) 


End of transmission ~ A communications. control sequence used to indicate the 
conclusion of a transmission that may have contained one or more text and any 
associated headings. The sequences may also be used to indicate a ‘no traffic’ in 
response to a poll. 


End of text ~ A communications contro! character used to terminate a sequence of 
characters started with STX or SOH and transmitted as an entity. 





| The RID, SID, DID address trio shown in Figure 1-3 may also make use of a general 
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Table 1-1. Control Character Description (Part 2 of 2) 


ASCII 


i 
Negative acknowledgment — A negative reply response used to indicate receipt of a | 
garbled message. The condition may reflect bad status, block check errors, or line 
probiems. 





Remote identifier - RID characters are used to address a remote station, a message 
switching center, or a group of terminais. The number of RIDs may vary. A minimum 
address must at least contain a RID character. 


Station identifier - SID characters specify 3 specific terminal that may be connected 
to the communications line by appropriate facilities or via a message switching 


center. The number of SID characters in a station address may vary depending on 
system requirements. 


Start of header - A communications control character sometimes used at the 
beginning of a sequence of characters that constitutes a machine-sensible address or 
routing information. This sequence is referred to as the header. 


Start of text - A communications control character that precedes a sequence of data 
characters that is to be treated as an entity. Such a sequence is referred to as TEXT. 
STX may be used to terminate a sequence of characters (headings) started by SOH. 


Synchronous idle — A communications control character used by a synchronous 
transmission system to provide a signal from which synchronism may be achieved or 
retained. . 








identifier (GID). This GID may be used in place of the RID, SID, or DID. For the RID, a 
GID = 2016 is recognized by all remote installations as its RID. For the SID, a GID = 
5016 is recognized by ail terminals at an installation. For the DID, a GID = 7016 rere 
addresses the station without selecting an nepaulcs device. 


Summary of GIDs: 


RID SID DID 


All groups 


All terminals in one group 


Station only 


ome eee ee ene am eum ees emme Gee ome eae 


Example: Destination Station: Device 
BLUEBELL U100#2 Printer 
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Following the address trio are control characters that determine the type of message 
being transmitted. For instance, a poll is the name given to a particular message header 
that solicits or requests input. If an end-of-text (ETX) character was encountered 
immediately after the address trio, the message is designated as a traffic poll. A traffic 
poll is one that simply requests the other terminal's identification. If an ENQ character 
followed by an ETX was encountered, the message would be designated as a status 
poll. A status poll is one that requests a response from the terminal. If the message is 
not a. poll message, the control character next seen is a data link escape (DLE) 
character. This signifies that some type of supplementary control information is coming. 
(See Figure 1-4.) An ACK followed immediately by an ETX signifies that the message 
is a positive acknowledgment (ACK). If the message is a negative acknowledgment 
(NAK), a NAK character follows the DLE. 


If the message is a text message, a start-of-text (STX) control character follows the DID 
without a DLE character. This is followed by the text and ends with an enc-of-text 
(ETX) character (tail). All messages then end with a BCC character, which is a parity 
check character used to detect transmission errors. 


The message header and the tail together comprise what is known as a message 
envelope. It is normally the job of a remote device handler to build this envelope on 
transmittals and strip it on reception of messages. In the physical interface, it is the job 
of your program. Once this set of rules and regulations has been solidified, the system 
is ready to receive data and must now consider how to handle the data coming in and | 
‘going out of the buffer areas. 


Example 1 — Sending an auxiliary device command 


Carriage Retum 








Print (write)* 
rca [svnfsva] svn] svn ]s0n no [0 [ow [svx]ocz] erx[sce 


Print (read)* 


*The DID determines interpretation as either a read-head or write-head cormmand. 


Figure 1—4. Typical Communications Message Envelopes with Control Characters (Part 1 of 2) 





UP-9746 SPERRY OS/3 1-8 
ICAM COMMUNICATIONS PHYSICAL INTERFACE (CPi) 





Example 3 ~— Sending to a UNISCOPE terminal 





(Format) 


Ennen oes A Se 


UNISCOPE Commands 


(Machine Language) 


Lt Ls [oe [ve Jon Jo fos po [oe Jo foo pa 
: : 


General DID Line 6 Row 10. State * 
Text] 03, 


Figure 1~¢. Typical Communications Message Envelopes with Control Characters (Part 2 of 2) 


In Figure 1-4, example 3 shows a typical message envelope for a UNISCOPE visual 
display terminal. Following it is a hexadecimal machine language representation of the 

™ format. The hexadecimal code equivalents are obtained from Figure 1-3 and Tables 1—1 
-and 1-20. The following example is typical of what your assembler source code must 
do to construct this message envelope: 
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BEGIN START 8 


BAL 12, UWRITE1 Set up message 


TRMADR1 DC X‘23557888' Destination termina! address 
BAL 12,SEND Go to send routine 
B FINISH 


UWRITE1=—MVi- = OTBF,1 
MVC OTBF+1(3),TRAMADR1 









mvC OORD+3( 2). MARGIN 
MV OTBF+4(6), COORD 
MVC OTBF+10(5), TEXT 
MVC OTBF+15(1),ETX- 
RETURN B 8(12) 
FINISH EOS 
0S OF 
OTBF DS CL1826 


MARGIN} OC X‘2529' 
COORD oc X‘S21B8BBO8OBF’ 


EXT pe | x‘83' . . qo. a 
a TEXT pc | cC‘HELLO’ Lf 
END 
farsa [epele [sale Tayepepeyrpe] 
$0 


As you can see, in the example we chose a particular installation and station with no 
auxiliary device addressed (235570). This was placed into our output buffer following 
the start of headers. Text was introduced by the start of text character (STX=02). 
Then we set the display terminal screen coordinates in front of our text. This control 
message is a cursor positioning code sequence but could just as well have been any 
display terminal function listed in Table 1-2. The cursor control code sequence was 
terminated with the shift in (Si=OF) character, followed by the text. Following the text, 
we terminated the message with an end of text. Finally, we would branch to our send 
routine to transmit the message. 


This is the typical kind of communications message for a display terminal that would be 
transmitted across a physical interface via software. The protocol and format 
comprising this message is known as the remote device handler discipline or the line 
discipline. This line discipline will vary for each device. It is the objective of ensuing 
sections to describe how this line discipline is constructed at machine level by a user 
program and how it interfaces with OS/3 at this physical level. 
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- 


Table 1-2. Control Codes and Control Code Sequences for a UNISCOPE Visual Display Terminal (Part 1 of 2) @ 





Cursor positioning ESC VT YX Si 
SOE positioning 

Cursor return (new line) 
Erase to end of display 
Erase to end of line 
Delete in line 

Delete in display 

Insert in line 

tnsert in display 

Scan left 

Scan right 

Scan down 


Scan up 





Character erase (space) 


Tab 


Tab stop set 


Tab stop 
Message waiting 
Cursor to home 
Insert line 
Delete line 
aan field 
Erase display 


Request processor message | - 


Start blink marker FS 
End blink marker GS 
Lock keyboard DC4 or ESC DC4 


Print DC2 





Print transparent ESC DC2 








UP-9746 SPERRY OS/3 1-11 
ICAM COMMUNICATIONS PHYSICAL INTERFACE (CPi) 


Table 1-2. Control Codes and Control Code Sequences for a UNISCOPE Visual Display Terminal (Part 2 of 2) 


Haxadecinsl Hexadecimal 


an of entry (SOE) 
Shift in (note 6) 
Shift out 

Line feed 


Form feed 


Transmit (unprotected) 





Transmit display ESC DCi 


1.2. GENERAL DESCRIPTION OF THE PHYSICAL INTERFACE 


An interface is basically defined as an interconnecting link between two systems. In 
data processing, this link may be either hardware or software. A physical interface is 
commonly considered to mean the link between the hardware (machine) and software 
(programming). It is often referred to as machine-level programming, since it has direct 


‘access to the hardware. In the integrated communications access method (ICAM), the 


communications physical interface (CPI) is the fundamental link between the single line 
communications adapter hardware and OS/3 communications software. This physical 
interface in ICAM is primarily intended to allow experienced programmers to write a 
user program at the physical level. In most instances it is used only when it is 
necessary to contro! a device or terminal that is not supported idk current ICAM 
software. 


The physical interface is a logical and physical packet-driven interface that gives you 
access to every command and status capability of the single line communications 
adapter (SLCA) hardware subsystem. The SLCA provides the hardware interface to a 
single communications line. The information necessary to control these communications 
lines is initially loaded into the SLCA. At the physical interface level, you must load this 
information via your user program. 


In the basic System 80 Models 3-6, up to two SLCAs are supported. With a single 
input/output microprocessor attached, Models 3-6 support one to eight SLCAs and 
Model 8 supports up to 14 SLCAs. With a dual input/output microprocessor attached, 
Model 8 supports up to 28 SLCAs. 


The physical interface is the lowest level of ICAM support. In essence, it merely 
provides activity scheduling within OS/3. It takes up the least amount of storage but 
also provides the least amount of services. Thus, the bulk of the work is left to you. In 
this interface, you must perform all the necessary initialization of the hardware. You 
must request and release the network and lines to be used, provide the device and line 
discipline, process the data, and perform all error detection and recovery procedures. 
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ICAM merély provides you with a formatted table and the necessary macroinstructions 
to schedule your communications task. In addition, you must construct the tables 
(packets) within your user program and supply the proper parameters in the proper 
sequences. Your user-own-code program is then submitted as a normal user job via a 
job control stream. 


If you need to write a program at this level, you should be thoroughly knowledgeable of 
assembler language programming and data communications generally, and single line 
communications adapter hardware specifically. It is strongly recommended that you 
become familiar with current versions of the following Sperry manuals: 


& integrated communications access method (ICAM) concepts and facilities, UP-9744 
= = interfacing a remote device handler programmer reference, UP-8424 
m input/output microprocessor programmer reference, UP-8909 


The physical interface actually has the dual role of servicing physical-level user programs 
and linking higher-level user programs via remote device handlers. This manual is 
primarily written for the physical-level user program; however, it does contain a great 
deal of information concerning remote device handlers, since the two are so closely 
related. 


1.3. TERMINOLOGY USED IN THIS MANUAL 


To retain a link with former versions of this manual, yet simplify terminology, you can 
also refer to the CPI as the physical interface. The communications physical input/output 
control packet (CPIOCP) is also called the control packet. The communications control 
routine user program is, simply, the user program (your program). 


1.4. PHYSICAL INTERFACE MACROINSTRUCTIONS AND PACKETS 


If you are familiar with data management or the use of macroinstructions, you probably 
have some understanding of the relationship between imperative and declarative 
macroinstructions. 


The imperative macroinstruction causes the generation of executable code sequences in 
the user program. These code sequences are the link between your user program and 
the input/output portions of the supervisor (in our sphere of interest, the extension of 
the supervisor known as ICAM). The imperative macroinstructions are used to request 
services of the supervisor and direct operations of the user program. Operands used 
with the imperative macroinstruction point to the file described by a declarative 
macroinstruction and specify the processing action to be taken. 
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Access to the physical interface is supported by ICAM solely via the imperative 
macroinstruction CCRCALL, which defines entry to the physical interface through the 
communications control routines and identifies the associated control packet. This 
macroinstruction identifies a control packet that must be aligned on a_ full-word 
boundary. (The CYIELD and CAWAKE macroinstructions are available to the physical 
interface user to release or activate the communications task.) Before execution of the 
instructions generated by a CCRCALL, the referenced contro! packet fields must have 
been set according to Appendix A. 


Format: 


LABEL AOPERATIONLA 





OPERAND 












{symbol] CCRCALL [ee eee eeeettes 
(1) 
Label: 
symbol 
An alphanumeric character string up to eight characters long uniquely 
identifying this instruction. 
Parameters: 


nie. 


CPIOCP- Label 
identifies the symbolic name of the control packet. 


(1) 
Indicates that the address of the control packet to be accessed is contained in 
register 1. The high-order byte of the register must be zero (X‘00’). 

IRL=NO TG . 
May be used by the remote device handler to indicate that the control packet 
does not request immediate return line (IRL) of control following execution of 
the instructions generated by the macroinstruction. 

NOTE: 


The CCRCALL macroinstruction generates a service request interrupt for the physical 
user program, but it generates a BALR instruction for remote device handlers, since they 
are an integral part of ICAM. 


The declarative macroinstruction provides inline expansion of nonexecutable code, such 
as define constant (DC) and define storage (DS) statements. Declarative 
macroinstructions are used to allocate areas in main storage to describe all aspects of a 
file to be processed. 


Figure 1-5 illustrates the parallel structure of imperative and declarative 
macroinstructions that exists between data management and ICAM, since ICAM, in 
effect, is a set of data-management-type macroinstructions used to control 
communications input/output operations. 


DMOUT PRCD,BUFFOUT 


DMINP PRCD,BUFFIN © 


CREATES A SERVICE 


SPERRY OS/3 


ICAM COMMUNICATIONS PHYSICAL INTERFACE (CPI) 


DECLARATIVE MACROINSTRUCTION 


TYPICAL CONSOLIDATED DATA MANAGEMENT 
STRUCTURE 


PRCD 
PRRB 


CDIB CUP 1 


RIB 


FILENAME=MAGFILE 
BFSZ=n, IOAREA=IOBUF 1 


CREATES A 
CDIB TABLE AND 
RIB TABLE 
SUCH AS 


PRRB 


em | ero 


filename 


completion status 


10 area 1 address 


ioe 


IMPERATIVE MACROINSTRUCTION 


TYPICAL CONSOLIDATED DATA MANAGEMENT 


STRUCTURE 
or 


CALL SUCH AS 


DY(®) 
,=ACPRCD) 

®, =A(BUFFOUT) 

49(1),X'20! 
15,52(1) 

98 


CNOP 
oc 
Svc 
oc 
EQJ 


DS 
svc 
svc 


PUTCP 


GETCP 


TYPICAL ICAM 
STRUCTURE 


DTFCP TYPE=CT, 


ERRET=NOGET 


CREATES A 
DTFCP TABLE 


indicators 


TYPICAL ICAM 
STRUCTURE 


CUP 1, BUFFOUT 


or 


CUP1,BUFFIN 


CREATES A SERVICE 
CALL SUCH AS 


@,4 

X' 97000700! 
98 
AL2((0*/8++5) 


SYSTEM 





Figure 1-5. Comparison of Data Management and ICAM Structures 
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The declarative and imperative macroinstructions operate together similarly for both data 
management and most levels of ICAM. However, at the physical level, there is no 
declarative macroinstruction to construct the control table or control packet. You must 
do this yourself via assembler DC and DS instructions. For exampie, to construct the 
DTFCP table (CUP 1) in Figure 1~5, we might perform the foliowing code: 


Example 1: 
CuP 14 oc Fig! Indicators 
oc ACPRF1) Process file name 
DC ACSRC1) Source name 
DC = AC GOOD 10) "Completion address 
DC ACBUFFIN) Buffer address 
oc ACERRI) - Error routine address 


Thus, instead of using the declarative macroinstruction to format and construct the 
needed information packet, we merely build it using standard assembler instructions. 


Let's briefly look at the actua/ control packet (Figure 1-6) that is used to pass the 
required information across the physical interface. This is shown functionally and 
detail in Appendix A, but here we just want to look at its structure. 


ote 


RDH: line contro! teble address 
user program: iine request fields, auto © butter, trace 





LEGEND: 
“" System-susplied parameters 


Figure 1-6. Communications Control Packet Basic Format 
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We could build this control packet with the following typical coding, which we might _ @ 
call “hard coding”: 
Example 2: 
OTPTPKT DC F'gt Priority/activity control 
pc ACCOMPADDR) Completion address 
oc F'g! Flag field 
DC F'@! Status field 
DC Fig! Sense bytes 
oc XL1'00! Clear command code 
Dc AL3(OUTBUFF ) Output buffer address 
pc H's! 3-sec time allocation 
oc H'47! Buffer Length 
SOFTFUNC DC YL1 Logical command 
pc XL3'0@! Chain address 
oc F'g! Operational flags 
SLCANO DC XL4'96006000' Channel, SLCA number and port number 
DC Fro! Reserved for ICAM 
pc Fro! Reserved for ICAM 
oc F'g! System 8@ sense bytes 
oc Fig! System 8@ sense bytes 





When we wish to perform a particular communications input/output function, we now 
only need an imperative macro that points to this contro! packet. However, in many 
programs, multiple control tables are desirable and the hard coding method of 
constructing them is both repetitive and time consuming. The use of dummy sections 
(DSECTs) reduces the amount of coding required by providing you with all the symbolic 
names and. values for accessing and setting any portion of the packet that might be - 
required. 


1.5. USE OF DUMMY CONTROL SECTIONS (DSECTS) 


A special assembler directive is available in OS/3 to generate dummy control sections 
(DSECTs) that can be shared by a user program. A DSECT permits you to define 
symbolic addresses in your user program without requiring any additional storage 
allocation for them. This allows you to map or overlay a storage area in your program 
with a set of symbolic addresses (labels) that were previously constructed for you in a 
dummy control section of the system software. Thus, you can map a storage area in 
your program with a set of labels without allocating space within your program. | 
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Displacement and base addresses are calculated by the assembier for each symbol 
defined by the DSECT, but they do not become part of your object program. This 
facility is especially useful in ICAM for control table access and manipulation, thereby 
considerably reducing the size and complexity of the programmer's coding task. This is 
most evident in the physical interface user program. This is because, in the physical 
interface, the use of multiple control tables for various functions is quite advantageous. 
The format and size of the tables may be identical, but the contents differ for each 
function. Using DSECTs, you need to perform only a simple allocation statement in your 
user program for each table required and then map it with the DSECT. 


For instance, suppose you wanted to construct an imaginary control packet for a 
network request and another for a transmit function. Instead of labeling each word and > 
byte in each table, as well as all the commands, flags, and status settings, you could 
use a single precoded DSECT to map any number of packets. As an example, let's 
make up a single fictitious DSECT, such as the following: 


Example 3: 


THPKT DSECT 


THFUNC DS XL1 Function (command) 

THFLGS DS XL1 ' Flags 

THRESV ODS XL2 Reserved 

THBUFADR DS XL4 Buffer address 

THCMPLAD DS XL4°— = Completion address 

THPRIM OS XL1 Primary status 

THOETL os XL1 ' Detailed status 

THSENS1 DS XL1 Sense byte 1 

THSENS2 DS XLi Sense byte 2 

* EQUATES FOR TABLE SETTINGS 

® Commands 

T#H#SEND -. EQU X'O1" — sf : Send. Rete yf 
_ THPDTR EQU) =-X'O2' Set data terminal ready 

THEDI EQU = X'@3! . Enable data input 

THLREQ EQU  X'2C! Line request 

THNREQ EQU  xX'2D! Network request 

* Status settings 

THEND EQU . X'@1! Message completion 

THPROGE EQU X'62' Program error 

THPAR EQU) = X'@3! Parity error 

THBUSY EQU = X'04! Busy 


if this fictional DSECT existed in the system software, you could call it in for availability 
to your user program immediately following the START instruction of your program, as 
follows: 


START @ 
TNHDSECT THPKT 


where T#PKT is an operand that specifies the dummy control section. 
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This DSECT, in effect, would allocate a table of constants and equates in system 
storage that would functionally appear as: 


T#FUNC T#FLGS TN#PRESV 






T#BUFADR 





T#CMPLAD 
T#PRIM T#SENS1 T#PSENS2 


These symbolic names could now be used in your program and you could very simply 
define multiple control packets by mapping or overlaying this DSECT on the control 
packet storage allocated in your program. For brevity, we'll assume just two packets: 
therefore, only two DS statements are required, but it could just as easily be a hundred. 


SENDPKT DS 4F'@! A 4-word control packet 
for transmit functions 
. .NTRQPKT DS 4F'o! A 4-word control packet 


for network request functions 


To overlay the first packet, first load register 1 with the address of the storage area 
defined for our transmit control packet (SENDPKT). Then, use a USING statement to 
specify that register 1 is the cover register for the desired DSECT; e.g.: 


LA R1,SENDPKT 
USING. THPKT,R1 


This technique in effect maps (or overlays, if you prefer) the SENDPKT storage area with 
the labels of the constants and equates of the T#PKT dummy control section. You can 
now use these labels in your program to fill in the control packet with the information 
necessary to perform a specific function. 


If we wished to use a network request function, we could do this simply by doing a 


LA R1,NTRQPKT 
USING THPKT,R1 


and we would now have our NTROPKT storage area mapped by our dummy control 
section. 


Putting this all together, if such a DSECT was available, we might use it as in Example 
4. 














UP-9746 


Example 4: 


BEGIN 


REQNET 


NREQCMP 


SEND 


SENDCMPL 


ISSUE 


SENDPKT 
NTRQPKT 
MSGBUF 


SPERRY OS/3 


ICAM COMMUNICATIONS PHYSICAL INTERFACE (CPI) 


START © 
TNHDSECT T#PKT 
BALR R3,0 
USING *,R3 
USING THPKT,R1 


- | Application code 


LA R1,NTRQPKT 

MVI THFUNC , THNREQ 

MVC) =o THCMPLAD ,, =ACNREQCMP ) 
B ISSUE 


: Status checking 


B SEND 


LA R1,SENDPKT 

MVI THFUNC , THSEND 

MVC «THBUFADR, =ACMSGBUF ) 
MVC T#CMPLAD,=ACSENOCMPL ) 
B  . ISSUE 


2 Status checking 
CCRCALL (1) 


EOJ 
oS 3F'o! 
oS S3F'o! 
DS 16F'@! 
END 


Call required DSECT 
Set program relative ® 
Begin program here 
DSECT covered by R1 


Map packet 

Set command 

Set completion address 
Issue 1/0 


Map packet 

Set command 

Set data address 

Set completion address 
Issue 1/0 
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As you can see, first the network request control packet is mapped, the DSECT labels 
are used to fill in the packet with the relevant information, and a branch is made to 
issue the imperative macro. When the service request is completed, control returns at 
NREQCMP, which was specified as the completion address. At this point, the available 
DSECT labels could be used to perform status checking, such as: 


CLI. T#PRIM, THEND Good completion? 

BE CONTINUE 

CLI THPRIM, THPROGE Program error? 
etc 


The program might then branch to SEND where it now maps the SENDPKT control 
packet and again fills in the relevant data via the DSECT labels provided. 


It is important to thoroughly understand the use of dummy control sections before 
proceeding. As you will see in the following sections, this basic technique is used many 
times in writing a complete physical interface program. 


1.6. GENERATING ICAM 


You create your communications system as part of the system generation (SYSGEN) 
process outlined in the current version of the system installation user guide/programmer 
reference, UP-8839. You can have as many as 18 different ICAM symbionts that 
comprise your communications system; you create each one in a separate system 
generation. 


To generate an ICAM symbiont,: you code the parameters in the COMMCT phase of 
system generation. The COMMCT parameters include the network definition 
macroinstructions and message control program (MCP) parameters described in 1.7. 
You submit the COMMCT phase to the parameter processor SGSPARAM, which 
validates the specifications and produces a listing. You then run the prefiled job control 
stream SGSCOMMK to assemble and link the ICAM symbiont into the $Y$LOD library 
on your system resident disk volume. 


1.7. CP! NETWORK DEFINITION 


For your program to work with ICAM, you must define the network you are going to 
use. A network definition consists of a set of macroinstructions you submit to the 
COMMCT phase of the system generation process of the operating system. The ICAM 
load module created by this process is a symbiont. When you tone this symbiont, it 
becomes part of the supervisor. 
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eS A communications physical interface network is a dedicated network — that is, the 
resources assigned to it are available only to your program. 


The following shows the arrangement of physical users in a communications physical 
interface environment. 


TERMINALS 


ICAM COMMUNICATION 


BH Y SICAL OSehy PHYSICAL INTERFACE/ 


REMOTE DEVICE 
HANDLER 


SINGLE LINE 
COMMUNICATIONS 


CHANNEL CONTROL 
ROUTINES 





Since only the physical interface and channel control routines of ICAM are provided in a 
communications physical interface environment, your network definition is extremely 
simple — only two macroinstructions are involved: CCA and ENDCCA. 


Format: 


LABEL AOPERATIONA OPERAND ea ae 
ee. “~ — PIOCS CCA USERS=n _ ee 
Label: 


Procs 
Required for a communications physical interface network only. 


Parameter: 


USERSenumber 
Applies only to the communications physical interface and is the decimal 
number of physical user programs that will use the physical network. 


Example: 


PIOcs CCA USERS=2 
ENDCCA 
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The message control program (MCP) section of the COMMCT phase specifies the 
volume that the ICAM symbiont is to be placed on and the name of the symbiont. In 
addition, the CACH parameter identifies each SLCA accessed or supported by the ICAM 
symbiont. If you specify half-duplex or full-duplex mode operation in word 10 of the 
CPIOCP, you must also specify the corresponding mode in the CACH parameter. For 
instance, if you specified asynchronous, 9600 baud, full-duplex mode in the port control 
word and CPIOCP, the corresponding COMMCT would look like: 


COMMCT 


PIOcS CCA USERS=2 
ENDCCA 
MCP 
MCPNAME=M3 
CACH=(08 , 9600, FULL) SLCA#1,960@ baud, full -duplex 
END 


Physical interface network definitions must be the last ones specified when a multiple 
CCA ICAM is generated. 

1.8. ICAM INITIALIZATION 

You must load ICAM before you can execute any communications user programs. ICAM 
resides in main storage until the last communications user program is terminated (unless 
you specify the KEEP parameter). Then ICAM shuts itself down. : 

The KEEP parameter keeps the ICAM symbiont loaded until cancelled by the system. 
operator or if ICAM experiences an unrecoverabie error. For example, if you load ICAM 
_ symbiont M3 by keying in: 

_M3 KEEP 


ICAM remains loaded after all user programs are terminated. 


1.8.1. Loading an ICAM Symbiont 


Always load ICAM in an idle system to avoid main storage fragmentation. You joad 
iICAM from the system console by keying in the operator command: 


ee aaa 
Mn 
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where: 


Cn or Mn 
Is the ICAM symbiont name specified on the MCPNAME parameter in the 
COMMCT phase of system generation. 


KEEP 
Keeps the ICAM symbiont loaded until cancelled by the system operator or 
ICAM suffers an unrecoverable error. 


You can also load ICAM from a job control stream with the statement: 


// a he cade 
Mn 


This allows you to load ICAM by means of a workstation instead of asking the console 
operator to do it for you. 


You can use the CC job control statement in two ways: 


1. In a job control stream that only loads ICAM: 
// JOB jobname 
//acta! ee mal 
Mn 
/& 


2. In a job control stream that executes your program. The CC job control statement 
immediately follows the JOB statement. 


| NOTE: 


Even if you load ICAM by job control, ICAM messages are still directed to the 


operator's console. 


1.8.2. Loading Your Program 


You load your program the same way as any other user program. That is, you submit a 
job control stream defining the devices, program name, and any data associated with 
your program. You must always assign a printer. 


You can execute your program in the same job control stream that loads ICAM or in a 
separate job control stream. If you execute your program after ICAM is loaded, wait 
until the ICAM READY message is received. 
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2. Writing a User Program 


2.1. GENERAL 


We have seen the similarities in programming structure between data management and 
ICAM. We have also discussed the use of dummy control sections to aid in 
constructing our control packets. However, since data communications takes place over 
communications lines, communications programming has a number of additional 
functions that data management does not. 


As discussed in 1.1, all communications programming is basically the same in structure, 
3 so let's put these functions in logical order and then see how they specifically apply to 
@ ~the physical interface. In Section 1, we mentioned such items as loading the single line 
. communications adapter (SLCA), requesting networks and lines, and providing line 
discipline. Figure 2—1 shows a block diagram of the basic functions required in the 

physical interface and summarizes the basic steps required to perform these functions. 





Ae 
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PRESET PORT 
INITIALIZE 

PRESET CHARACTER 

DETECT TABLE 















PRESET CHARACTER 
INTERPRETATION TABLE 


FIRST LINE 
ENTRY 

ONLY 
(FOR EACH 
LINE) 














LOAD PCW 







LOAD COT 





LOAD CIT 


SET DATA TERM READY 


TRANSMIT/ 
RECEIVE 
DATA 


trutiahze the programm. 
ininalze the SLCA tables, if applicable. 


Request the network. 

8. Load the cover register with the request packet. 

b. Ful the packet with the network request command and intormation. 
c tasue the CCRCALL. 


Request the ine. 
Load the cover register with the request packet. 


Fill the packet with the line request command and information. 
Issue the CCRCALL. 


Loed the cover register with the request pecket. 
Fill the packet with the clear ine sdapter command and information. . 
issue the CCRCALL. 


Fi the packet with the load PCW commend and information. 
e issue the CCRCALL 
Load the SLCA character detect table. 
s Load the cover register with the request packet. 
e Fill the packet with the load COT command and information. 
C) issue the CCRCALL. 
Load the SLCA character mierpretation tabie. 
s Loed the cover register with the request packet. 
Fill the packet with the toad CIT command and function. 
t ] issue the 
Set the Gata terminal reedy. 
s Losd the cover register with the request packet. 
s Fill the packet with the set OTR command and function. 
s issue the CCRCALL. 


Transm the data. 

2. Load the cover register with the input/output packet. 

b. Full the packet with the send dats command and information. 
c. issue the CCRCALL. 


Release the tine. 

a. Load the cover register with the request packet. 

b. FW the packet with the retesse lime commend and information. 
c. issue the CCRCALL. 


Release the network. 

a. Load the cover register with the request packet. 

b. ‘Fill the packet with the relesse network command and function. 
c. . isaue the CCRCALL. 





Figure 2—1. Structure of a Communications Physical Interface Program 


As you can see in Figure 2—1, most of the functions required are simply unique formats 
of the control packet. The bulk of the task, therefore, simply breaks down to: 


m Load the cover register with the desired packet. 


m Use the DSECT labels to fill the control packet with the relevant parameters. 


= Use the imperative macroinstruction to call the service request for the relevant 


control packet. 
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The only exception to this task is on initial line entry. Before each initial line entry, the 
SLCA must be loaded with the port control word, character detect table, and character 
interpretation table. We must tell the control packet that we are using our own user 
discipline and supply the appropriate port control word, character detect table, and 
character interpretation table to be loaded. These additional tasks will be considered in 
detail in following sections. 


But, for now, let’s make up some simple symbolic labels for the functions in Figure 
2-1, such as: 





Label Routine 
NETREQ 1 Scien the network. 
LNEREQ 1 Request the line. 
INITLINE Initialize the line. 
SETRMRDY Set the terminal ready. 
_ SENDMSG Transmit the message. 
LNEREL1 . Release the line. 
NETREL1 Release the network. 
Label Control Packet Function 
| REQPK Request control. 
SETDTRPK Set data terminal ready. 
_INPTPK Input | 
OTPTPK Output 





Using these symbolic labels, we can code a basic outline of our communications 
program in Figure 2-2. The procedures in Figure 2-1 are numerically keyed to the 
labels in Figure 2—2 for easy identification (items 1a, 1b, etc). Following this outline, the 
rest.of this section describes how to use the dummy control section labels to set the 
parameters in the control packet for each function. The dummy control section fields are 
shown here for ease of use, but are discussed in detail in Appendix A. The fields and 
the actions performed on them for each function are then numerically keyed to a typical 
coding example. : 





+e: 
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Byte 


12 gree. esas sos ee 
~ we 


36 TN#PCHNL TN#PPORT 








NOTE: 


You must specify the channel number (in field TN#PCHNL) and the SLCA number (in field TN#PPORT) for all CPI requests, 
including a network request. The channel numbers can be hexadecimal 02, OD, or OF, and the SLCA number range can’ 
be hexadecimal 01 to OF or O08 to OF, depending on the System 80 model type (Table A-6). For example, because 
TN#PMUX is the half-word label for TN¥PCHNL AND TN#PPORT, you can specify: 


MVC TNHPMUX,=X'6208' 
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(4) LNEREQ1 


Ga) INITLINE 
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USING TN#PARP,R1 


LA R1,REQPK 


. Set parameters i 


CCRCALL (1) 

LA R1,REQPK 

7 Set parameters 
CCRCALL (1) 


LA R1,REQPK 


. Set parameters i 


CCRCALL (1) 


LA R1,REQPK 


CCRCALL (1) 


LA R1,REQPK 


. Set parameters i 


- detect table 


CCRCALL (1) 


Eh Set parameters i 


control packet for network request 


control packet for Line request 


control packet for line adapter clear 


control packet for Load port control word 


control packet for load character 





Figure 2-2. Skeleton Program Outline for the Physical interface (Par: 1 of 2) 
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LA R1,REQPK 


Set parameters in control packet for load character 
5 - interpretation table 


CCRCALL (1) 


Ge) SETRMRDY LA R11, REQPK 


(6) SENDMSG 


(@) LNEREL1 


(8) NETREL1 


. Set parameters in control packet for set data terminal ready 
CCRCALL (1) 

LA R1,OTPTPK 

. Set parameters in control packet for send message 

CCRCALL (1) 

LA R1,REQPK 

. Set parameters in control packet for release line 

CCRCALL (1) 


LA R1,REQPK 


Ge Set parameters in control packet for release network 


CCRCALL (1) 





Figure 2-2. Skeleton Program Outline for the Physical Interface (Part 2 of 2) 
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In 2.8, the coding discussed for each function is merged into one basic program to 
illustrate what an overall physical user program would look like. In this example, 
completion routines containing status, sense, and condition code checks are not shown 
to keep the size of the program manageable and the structure visible. Section 4 
describes how the port control word, character detect table, and character interpretation 
tables are constructed for standard and unique user line disciplines. 


2.2. REQUESTING A NETWORK 


The first function that any communications programm must perform is to request the 
network of lines and terminals desired. Referring to the dummy control section (DSECT) 
for our control packet, as detailed in Appendix A, the fields that require setting for the 
network request function are: 


Field Action 

@) TN#PLINK — Set to 0. 

(2 TN#PFUNC Set to TN#PNREQ. Bits O and 1 are not interpreted. 
Using the programming techniques discussed in Section 1, we load the base address of 
our dummy control section via the USING statement-and map the control! packet area in 
cur user program by loading the address of the control packet in register 1. We now 
set the required fields by performing the following typical coding, using the relevant 
labels of the dummy contro/ section: 


‘NETREQ -EQU * 


LA R1,REQPKT : Map packet 

z MMVI TNHPCMMD , 0 Clear command 

@) XC’ TN#PLINK, TNHPLINK No chaining . 

@® - MVI -TN#PFUNC, TN#PNREQ Set function command 
MVC TNHPFCPL,=ACNTREQCMP) Set completion address 
LH R3, TIMES Set time-out 
STH R3, TNHPTIME 
CCRCALL (1) Issue 1/0 request 


In this coding, the request packet address is first loaded in register 1 for mapping 
purposes. The hardware command code is then cleared to signal !/O control (CPIOCS) 
that it must translate the logical command in TN#PFUNC to a hardware command and 
to overlay it on the TN#PCMMD byte. If this is not done, |/O control uses whatever 
_ hardware command currently resides there. Next, data chaining is inhibited by clearing 
the address field, and the function to be performed is inserted in the function field. The 
1/O completion address is set and a 3-second time-out is inserted. Finally, an 1/O 
request is issued by the CCRCALL macroinstruction. : 


Ed 
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The user program is assigned one of activity control's user activity slots when it issues 
its network request function (or, under the temporary option, when it issues its first 
CCRCALL for whatever function). If a user activity slot is not available, the user program 
is cancelled and the control packet identified by register 1 has TN#PRIM set to 
TN#PROGE and TN#PDETL set to TN#PMNCE. Refer to 3.6 for other conditions that 
result in the user program being cancelled by the interface code. 


If the user program operates as a multitasked job, all access to the physical interface 
should be via one specific task. Should the user program access the physical interface 
by means of more than one task for one job, each task would be assigned one of 
ICAM’s task identities. 


While the user program is executing communications |/O requests, it must not be 
executing other |/O requests using the same task. The user program’s task identity is 
deleted and its lines are released when it goes to end-of-job (EOJ) either normally or 
abnormally. 


After the supervisor request call issued via inline expansion of the CCRCALL has been 
completed successfully, control returns to label NTREQCMP as set in the completion 
address portion of the control packet. 


Normally, at this point in your program, you would want to perform clean-up tasks, 
such.as checking completion status. Again, using the DSECT labels available to you, you 


-eould check logical status bytes, such as: 


CLC TNHPRIM(2),=X'O180' Good completion? 
BE LNEREQ1 Yes, perform Line request 


The status bytes are interrogated by assembier statements using labels in the control 
packet DSECT. The number of checks available to you is rather large; os degree of 
checking is your option. 


2.3. REQUESTING A LINE 


Once the network request is completed satisfactorily, you must request the specific line 
on which you wish to communicate. 


All user program attempts to execute functions without prior request and assignment of 
a line are aborted. Your user program must secure the desired line and a set of 
communications adapter interpretation ‘tables before it can issue I/O functions. Do not 
attempt a line request while non-CPI line requests are in progress. 


To request a line, the user program must set the following contro! packet fields as 
directed. Those fields not specified here are set as specified in the control packet 
description in Appendix A. 
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Field 


TN#PMUX 
TN#PFUNC 
TN#PLINK 


TN#PDSPL 


TN#PCAID 


TN#PBLTH 
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Action 


Set byte O (TN=PCHNL) to 02, OD, or OF depending on your 
System 80 model type (Table A-—6). Set byte 1 to the SLCA 
number and byte 2 to the port number. 


Set to TN#PLREQ. Bits 0 and 1 are not interpreted. 
Set to O. 


Set bit O to 1 and set bits 1-3 to any value. A user program key 
is placed into bits 4—7 to create a unique user remote device 
handler discipline ID. 


Set from OO: to 0216. The SLCA has two control character 
detect tables and one control interpretation table. When this byte 
is set to OO16, an available set of tables is located and the ID is 
placed back in TN#PCAID. The user program can optionally 
specify the tables it wants (0116 — 0216). 


The SLCA buffer size must be specified in the TN#BLTH field of 
the CPIOCP at the request time. The valid range is 32—256 in 
decimal. If buffer toggling is required, the line buffer size must be 
an even multiple of the SLCA buffer size. 


Translating these actions into actual coding, we might have something like this: 


‘LNEREQ1 = EQU 


@ 


g 


680 


LA 
MVI 
— MVI 
MVI 
MVI 
xc 
LH 
STH 
MVC 
MVI 
MVI 
MVC 


* 


R1,REQPKT 
TNHPCHNL,2 
TNHPPORT,8 
TNHPCMMD , © 
TNHPFUNC, TN#PLREQ 
TNHPLINK, TNHPLINK 
R3, TIMES 

R3, TNHPTIME 
TNHPFCPL,=A(LNREQCMP) 
TNHPDSPL ,X'80! 
TNHPCAID, 1 
TNHPBLTH+1,H'256! 


CCRCALL (1) 


LNREQCMP EQU 


* 
INITLNE 


Map packet 

Set to channel 2 

Set to SLCA#1. 

Clear command 

Set function command 
No data chaining 

Set time-out 


Set completion address 

Set for user own discipline 
Set for COT1/CIT1 - 

Set SLCA buffer length to 256 
Issue 1/0 request 


Line request completion routine 
Continue to next function 
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As you can see in the coding, the channel is set to channel 2; the SLCA is set to e) 
SLCA#1. The command is set to line request. For this example, we could have selected 
a remote device handler discipline (label TN=PDSPL). If we choose a remote device 
handier that is already supported, we must construct a port control word, character 
detect table, and character interpretation table according to the parameters pertinent to 
that handler. These parameters are described in Section 5. (An explanation of how to 
construct these tables with the relevant parameters is given in 4.2.1 through 4.2.3.) We 
chose instead to construct our own remote device handler discipline by setting bit O 
equal to 1. 





We have also specified that we want the number 1 character detect and character 
interpret tables. However, we could have requested any available set of tables by 
‘performing a 

MVI TNHPCAID,@ 


You will notice in the next section that line initialization need only be performed the first 
time that a particular line is requested. 


Some other considerations you should keep in mind when performing line requests are: 


ws A full-duplex line is assigned only if both ports are unallocated. 





‘A line with primary and secondary channels can be assigned only one channel at a 
time. A line request must first be made for the primary channel! port; then, a 
second line request should be made for the secondary channel port. Separate line 
requests must be issued for autodialer ports and the associated line. The dial 
commmand request will be illegal if the dial port and the line associated with the 
autodialer have not both been assigned to you. 


NOTE: 

Two simultaneous line request operations can cause an attach error condition to be 
presented (TN#PRIM=TN#PROGE and TN#PDETL=TN#PAATH) in one of the control 
packets (CPIOCPs). You can recover from this condition by reissuing the line request 
function for the control packet returned with the error status. 

2.4. INITIALIZING A LINE 

The following procedure is recommended to initialize a line once the line request 
function has been completed successfully. This procedure is identical to that performed 
by remote device handlers for other ICAM interfaces. 


m § Half-duplex lines: 


1. Issue line adapter (LA) clear (TN#PFUNC=TN#PFSL+ TN#PLACL). 





2. Load port control word (TN#PFSL + TN#PLB14). 


3. Load the SLCA control tables if not already loaded. 
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This consists of loading the character detect and character interpretation tables 
before the first transmission on the line. These tables are described in Section 
5. These tables must be constructed within the nonexecutable code of your 
program before issuing the load commands. As mentioned in 2.3, if the 
remote device handler discipline used is one of the supported handlers, the 
parameters prescribed may be used directly to construct the tables. This 
construction is described in 4.2.1 through 4.2.3. If your own unique discipline 
is to be used instead, you must then construct your own unique tables. 


Issue a set data terminal ready function (TN#PFUNC=TN#PFSL+ TN#PDTR). 
This enables receipt of the BREAK interrupt and permits dial connection. 


a Full-duplex line: 


1. 


2. 
3. 


4. 


5: 


Issue clear and load port control word for output port as explained for 
half-duplex lines. 


Load control tables. (Same as item 3 for half-duplex lines) 
Clear and load port control word for input port. 
NOTE: 


Port O is for special control, port 1 is for output, and port 2 is for input. The 


. 2-way alternate (half-duplex) operation, therefore, assumes port 1 is for both 


output and input if the set-full-duplex command is not set. For full-duplex 


operation, you specify port 2 for input by issuing the set-full-duplex command 
in step 4. See Appendix 


Issue _set-full-dupiex eee to output oe (Ti N#PFUNC = TN#PFSL + 
TNA eEEO MS 


Issue a set data terminal ready function (TN#PFUNC=TN#PFSL + TN#PDTR). 


Breaking each of these functions down to.our standard structure and using the 
half-duplex procedure, we would have: 


ws clear the line adapter; 


w load the port control word; 


m load the character detect table; 


us =load the character interpretation table; and 


= ~=set the data terminal ready. 
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Once the line has been initialized for the first time, these functions do not have to be 
performed again. Therefore, in the coding of the next section, we will insert a switch 
that falls through on the first entry and is then set to skip the initialization procedures 
on ensuing transmissions for this particular line. If other lines are to be used, they also 
must be initialized before the first entry. 





2.4.1. Clear the Line Adapter 
To issue a line adapter clear, we must perform the same steps of setting the relevant 
parameters in the control packet and making a service request via the CCRCALL. To 
issue this command, you must perform the following actions on the specified fields: 
Field Action 
@) TN#PCHNL Same as line request (see 2.3) 
@) TN#PPORT Same as line request (see 2.3) 


@ TN#PFUNC Set to TN#PFSL + TN#PLACL (start and end of message with 
line adapter clear command). 


Showing these actions in coding format, we might have: 





INITLNE EQU * 


SWITCH BC @, SENDMSG Initialization switch 
LA R1,REQPKT Map packet 
MVI TNHPCMMD , @ Clear command 
MVI TNHPCHNL, 2 
MVI TNHPPORT,8 
fo MVI ‘TN#PS8OP, 1 
@) ——-MVI_—_TNHPFUNC, TNHPFSL+TNHPLACL Set function command 
xc TNHPLINK, TN#PLINK No data chaining 
LH R3, TIMES Set time-out 
STH R3, TNHPTIME . 
MVC TNHPFCPL,=A(LACMPL) Set completion address 
CCRCALL (1) ; Issue 1/0 request 
LACMPL EQU * Line adapter clear completion routine 
MVI SWITCH+1,X'FO' ° Set to skip after ist time thru 


B LDPCW Continue to next function 











@ ie 
. 


@ 
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2.4.2. Load the Port Control Word 


Each port in the SLCA must have a port control word consisting of a set of four control 
bytes. These control bytes must be coded and loaded by your user program. The 
settings for these control bytes are determined by the characteristics you require for a 
particular remote device handler discipline. These characteristics are described in detail 
in Section 3 of the input/output microprocessor programmer reference, UP-8909 
(current. version). Briefly, byte 1 concerns details of synchronous/asynchronous 
operation. Byte 2 references the character detect table to use, the character length, and 
the asynchronous line speed, if applicable. Byte 3 references the character interpretation 
table to use, specifies whether to include or exclude the start character in the block 
check character count, and the type of parity to be used in transmission. Byte 4 
specifies whether operation is of the synchronous or asynchronous mode and timing 
intervals. 


Subsection 4.2.1 describes how to construct a port control word. At this point, we are 
basically concerned with loading it via our user program. So for now, let’s assume that 
we have a table in our nonexecutable code of the form: 


DCT2PCW DC X'8@ 20 19 62! 


Field Action 
G@) TN#PFUNC Set to load port control word (TN#PFSL+TN#PLB14). 
(2) TN#PBLTH Set to 4 bytes. 


() TN#PBADR Set to data buffer address. 


In our coding, we perform the following: 


LOPCW equ) * 


MVC OUTBUFF ,DCT2PCW Put port control word in buffer 
LA R1,REQPKT Map packet 
MVI TNHPCMMD ,@ _ Clear command 
@) MVI TNHPFUNC, TNHPFSL+TNHPLB14 Set function to load PCW 
@) MVI TNHPBLTH+1,4 ~~ Set buffer length to 4 bytes 
= LH R3, TIMES Set 3-sec time-out 
STH R3,TNAPTIME 
@ MVC TN#PBADR,OUTBUFAD Set output buffer address 
, xc TNHPLINK, TN#PLINK’ No data chaining 
MVC = TNHPFCPL,=ACLPCWCMPL) Set completion address 
CCRCALL (1) Issue 1/0 request 
LPCWCMPL EQU * Load PCW completion routine 


B LDCDT4 Continue to next function 
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Additional tasks performed in this routine are to reset a switch (such that this routine is 
entered only the first time this line is requested), put the port control word in the output 
buffer, prescribe the length of the data buffer that is to be transmitted, and set the 
output buffer address in the control packet. Standard tasks are to insert the load port 
control word command, and, of course, furnish a completion address. 


2.4.3. Load the Character Detect Table 


Each port in the SLCA references at least one of two character detect tables. These 
tables are used to produce start and end character functions, and access a character 
interpretation table word, if additional functions are required. Again, the character detect 
table must be coded and loaded by your user program. The settings for these bytes are 
determined by the characteristics you require. The characteristics are described in detail 
in Section 3 of the System 80 input/output microprocessor programmer reference, 
UP-8909 (current version). A discussion on how to construct a typical character detect 
table is contained in 4.2.2. Since this subsection is concerned only with loading the 
table, let’s assume there is a table in the nonexecutable code of our program that looks 
like: 


DCT2cDT DC X'ee12001317001414" 00 - OF 
DC —s_- X ' SEECEOERKECRECEE 
DC 3—-_ «X90 1480000014 1000" 10 - 1F 

a DC —_- X 99 080801308001400" 

DC —-_—- X  @BOERERECEDOOR—E . 20 = 2F 
DC —-_ X ' @eERESERDECECELO' 
DC = X ' SeEvEsERCECeoOFO 30 - 3F 
DC 3—s_ X ' @eeRESEEDEEEERO: 
DC —-_- X ' P9EREEEECEEORCCR 6@ - 4F 
DC -—s- X 'S9ECESRECEDEREEO' 
DC = X'@pwesCeeCeDeRCOe' —§ 50 - SF 
DC —-_—- X “@eeeREeeCECeeCee* 
DC —-_—- X ' SUEGOEGECEEECEO 60 ~- 6F 
DC —«-_- X ' SUREREEREECSEE—O' . 
DC —-_—- X ' SoBeRSEELEREREEE' 70 - 7F 
DC =—-_- X - Se@SELCERERECED' 
DC —s_- X 8900801300001400" 80 - 8F 
DC —«-_- X  PHEECPEEEECLCOCE' 
DC —«-_- X90 146009 @000R0000" 90 - OF 
DC —-_- X ' PEESEECEKEDERERD' 
oc X'SCOSSSCHOOSSSSOOSE * A®@ — AF 
oc X'$906090000000000 ' 
DC —-_—- X ' SEBEEREER—EEE' BO - BF 
DC —s_- X ' SEORELEEEEOSER—O' 
oc X'O800000000000000' C@ — CF 
DC —-_- X ' SEREREELEeOLERED' 
pc X' OSOCSSSSSSHSONE ¢ D® - DF 
oc X* SSOSCOSSCSOSOOSSOCG ' 
oc X' GSOSSSSCSHSOSSCSS ' E®@ - EF 
oc X'S9SOOSHSSOSOCSOSD6 ' 
DC —- X' PPODODROCEEOECRO' FO - FF. 


oC X'OSOOOHSHSOOOSGOO ' 
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‘To load this table into the SLCA, you perform the following actions on the specified 
fields: 


Field Action 
(i) TN#PFUNC Set to load character detect table number 1. 
(The CD table is always 1 or 2 (0016 or 0116) 
for the SLCA.) 
(@) TN#PBLTH Set to 256 bytes maximum. 
() TN#PBADR Set to the address of the data output buffer. 


To perform these actions on the specified fields, you do the following coding: 


LocDT1 EQU) * 


LA R1,REQPKT Map packet 
MVC OUTBUFF,DCT2CDT Put character detect table in output 
buffer 
MVI TNHPCMMD ,@ Clear command 
@) MVI ‘TN#PFUNC, TN#PLCD1 Set function to load CD table 1 
(See NOTE.) 
@) MVC = TN#PBLTH, W256 _ Set buffer Length to 256 bytes 
© ie et LH R3, TIMES - Set 3-sec time-out 
: STH R3,TNHPTIME 
3) MVC TN#PBADR,OUTBUFAD Set output buffer address 
XC TNHPLINK , TN#PLINK No data chaining 
MVC TNHPFCPL,=AC(LCOTCMPL) Set completion address 
CCRCALL (1) ; Issue 1/0 request 
LCDTCMPL EQU) * Load CD table completion routine 
B LDCIT1 Continue to next function 


NOTE: 


This command loads only character detect table 1. The SLCA allows two character detect tables. 


As in the previous section, the data to be transmitted to (loaded into) the SLCA is 
placed in the data output buffer, and the length of the output buffer and the address of 
the output buffer are placed in the control packet. Finally, the function and completion 
address are inserted and the !/O service request is performed via the CCRCALL 
macroinstruction. 
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2.4.4. Load the Character Interpretation Table 





There is only one character interpretation table in the SLCA. It is used to provide 
multiple sequences of action when addressed by the character detect table. That is, the 
character detect table may initiate a single hard-wired function or it may be used to 
initiate a function and address one word of the character interpretation table. Each 
individual bit in the character interpretation table word can then indicate a particular 
action or sequence of actions in the SLCA. Thus, multiple actions can be initiated by a 
single character. As with the port control word and the character detect table, you must 
code and load the character interpretation table via your user program. The settings for 
these bytes are determined by the characteristics you require. A discussion on how to 
construct a typical character interpretation table is contained in 4.2.3. Again, since 
we're concerned here with only the loading of the table, let's assume we have 
constructed a table in our nonexecutabie code that looks like the following: 


DCcT2CIT oC X'98010000' 
bc X' 11014800! 
oc X'91000000' 
oc X' 90000 160' 
oc X'9000G000' 
oc X'08000060' 
oc X'9O9000000' - 
DCX! epeoeee0! ee ee ee ee 











-e- os 


To load this table into the SLCA, you have to perform the following actions on the ei 
specified fields: 


@) “TN#PFUNC | Set to load character interpretation table number 1 
@) TN#PBLTH Set to 32 bytes maximum (16 words). 
@) TN#PBADR Set to address of data output buffer. 


To perform these actions on the specified fields, we use the same format as before to 
construct our table; the coding to do this looks like: 


LDOCIT1 EQU) * 





LA R1,REQPKT Map packet 
MVC OUTBUFF,DCT2CIT . out character interpret table in 
output buffer 
MVI TN#PCMMD,® Clear command 
@ MVI  TN#PFUNC, TN#PLCI1 Set function to load CIT table 1 
xc TNHPLINK, TNH#PLINK No data chaining 
Q@) MVI ‘ TNHPBLTH+1, 32 Set for 32-byte buffer 
G3) MVC TN#PBADR,OUTBUFAD Set output buffer address 
LH R3, TIMES Set time-out 


(continued) 
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STH R3,TNHPTIME 
r MVC TNHPFCPL,=ACLCITCMPL) Set completion address 
“CCRCALL (1) Issue 1/0 request 
LCITCMPL EQU) * Load CI table completion routine 
B SETRMRDY , Continue to next function 


2.4.5. Set the Data Terminal Ready 
After the SLCA is loaded, line initialization is complete and we can now issue the 
function to set the data terminal ready. This allows a BREAK interrupt to be received 
and permits dial connection. To issue this command, you must perform the following 
actions on the specified fields: 

Field Action 


a © ENE Set to TN#PFSL+TN#PDTR (start and end of message with set 
; @ . data terminal ready command) 


With the exception of entering this particular command, the coding again remains 
basically the same: 


SETRMRDY EQU * 


LA R1,REQPKT - Map packet 
' MVI- TN#PCMMD,© Clear command 
GQ) MVI TNHPFUNC, TNHPFSL+TN#PDTR Set function to set data terminal 
ready 
xc TNHPLINK, TNHPLINK 
MVC TN#HPBADR , AFAKEBUF Set fake buffer 
LH R3, TIMES Set time-out 
- STH 3, TNHPTIME 
MVC = =6TN#PFCPL,=ACSDTRCMPL) - Set completion address 
CCRCALL (1) Issue 1/0 request 
SDTRCMPL EQU * Set data terminal ready completion 
routine 
B SENDMSG Continue to next function 


@ The only unusual action in this coding might be use of a fake buffer (contents of zero) 
to clear the output buffer. The set deta terminal ready command does not require use of 
the output buffer, but clearing the buffer prevents any possible transmission of spurious 
messages or commands to a termina!. ; 
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2.5. TRANSMITTING THE DATA 
Transmission or reception of data are basically the same structurally. They differ only in 
the command and data buffer address supplied to the control packet. Reception of a 
message might differ only in performing a poll before performing the actual receive. In 
this case, a poll would merely be a send command control packet with a poll message 
in the data buffer. For the sake of simplicity, however, we'll only show a send text 
procedure. To do a send, we would perform the following actions on the specified 
fields of our control packet: 
Field Action 

( TN#PFUNC Set to send data command (TN#PSEND+TN#PFSL). 

(2) TN#PBADR Set to the data output buffer address. 

@ TN#PBLTH Set to the length of the output buffer. 
To perform these actions on the specified fields, we might code: 


SENOMSG EQU * 


LA R1,OTPTPKT Map packet 
MVI TNHPCMMD , @ Clear command 

@) _ MVI  TNAPFUNC, TN#PFSL+TNHPSEND Set function to send data 
MVC OUTBUFF,MSG1 Put text in output buffer 
xc TNHPLINK, TN#PLINK No data chaining 
LH R3, TIMES Set time-out 
STH R3, TNHPTIME 

@) MVC _TN#PBADR , OUTBUFAD Set buffer address 

@ MVI ‘TN#HPBLTH+1,86 Set buffer length 
MVC ‘TNHPFCPL,=ACSENDCMPL) = Set completion address 
“CCRCALL €1) | _ Issue 1/0 request 

SENDCMPL EQU * Send completion routine 

B LNEREL4 Continue to next function 


If we were performing a receive function, at this point, instead of continuing to the next 
function, we might want to construct a loop that would send a poll message for text. 
The text could then be scanned for an end message and, if obtained, a branch would 
continue to the next function to release the line. 


| 
: 
i 
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- 2.6. RELEASING THE LINE 


The line release function deallocates a line for assignment to other users. As with line 
requests, primary and secondary channels must be released separately (secondary 
before primary). An autodialer port and associated lines must also be released 
separately. 


Before a line release is issued, the user program must ensure that there are no 
outstanding control packets. If there are any outstanding contro! packets for the line, 
they may be retrieved by executing a CCRCALL with TN#PFUNC=TN#PFSL + 
TN=PIOFF. (The turn-off command does not provide an immediate status. The 1!/O 
completion interrupt must be awaited.) If the user program interface code detects an 
outstanding control packet, it will abort the line release function, setting 
TN=PRIM=TN#PROGE and TN#PDETL=TN#PFRMT. 


For this function, then, we'll actually perform two functions — one to issue the turnoff 
and one to issue the line release command. 


Field Action 
@) TN#PFUNC Set to complete message with turnoff (TN#PFSL+ TN#PIOFF). 
To perform the turnoff, we need only the following: 


as LNEREL1 EQU * 
LA R1,REQPKT Map packet 


MVI TNHPCMMD ,@ Clear command 

Q) MVI TN#PFUNC, TN#PFSL+TNHPIOFF Set function to turnoff 
xc TNHPLINK, TNHPLINK No data chaining 
LH R3,TIMES | Set time-out 
STH R3,TNHPTIME . a 
MVC = TN#PFCPL,=A(NOMOPKTS) ‘Set completion address 
CCRCALL (1) Issue 1/0 request 

NOMOPKTS EQU * Turnoff completion routine 
B LNEREL2 Continue to next function 
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vy 
} 





At the completion address, as just mentioned, one of the things you would want to 
check is if the outstanding packet check bit is set in the control packet. This could be @ 
done, for instance with a: 


CLI TN#HPRIM, TNH#PROGE Program error? 
BNE No 
CLI TNHPDETL, TNHPFRMT Outstanding packet? 
BNE ~ No 


Once the turnoff has been completed successfully, the line release function can be 
issued. 


Field Action 
@) TN#PFUNC Set to line release command (TN#PLREL) 
This function would be performed by: 


LNEREL2 EQU * 





LA R1,REQPKT Map packet 
MVI TNHPCMMD,®@ ' Clear command 
@) MVI TNHPFUNC, TN#PLREL Set function to Line release 
seragee cr reas 2 eS OE _TNHPLINK , TN#PLINK No data chaining 
es LH R3, TIMES Set time-out 
STH R3, TN#PTIME , 
MVC ‘TNHPFCPL,=ACLRELCMPL) Set completion address 
CCRCALL (1) Issue 1/0 request 
LRELCMPL EQU * | . Line release completion routine 
B NETREL1 4 % Continue to next function | 


2.7. RELEASING THE NETWORK 


The last CCRCALL that the user program executes should be a user program network 
release function to avoid abnormal termination by the supervisor. The user program 
network release function releases all lines that the user program has not yet released 
and disengages the user program from ICAM. The only field that needs setting for a 
user program network release other than the standard ones is: 


Field Action 


@) TN#PFUNC Set to TN#PNREL. Bits O and 1 are not interpreted. 
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@ You can perform the function of network release with the following typical coding: 


NETREL1 EQU 
LA 
MVI 
@) MVI 
xe 
LH 
STH 
MVC 


* 


R1,REQPKT 

TNHPCMMD ,@ 

TNHPFUNC, TN#PNREL 
TNHPLINK, TN#PLINK 

R3, TIME 

R3, TNHPTIME 
TNHPFCPL,=A(NETRLCMP) 


CCRCALL (1) 


NETRLCMP EQU 


Map packet 

Clear command 

Set function to network release 
No data chaining 

Set time-out 


Set completion address 
Issue 1/0 request 


Network release completion routine 


At this point in the program, there are no further functions to be performed and the 


next instruction would be an EOJ to end the job and start the constant area to define 
the required constants for the program. The communications task is now complete for 
this simple program. 


2.8. EXAMPLE OF A BASIC USER PROGRAM 


To illustrate all of the functions described thus far, 


Figure 2-3 shows ail of the 


Statements coded from 2.2 through 2.7 integrated as a simple program. The dummy. 


completion routines are all consolidated to save space and clarify the flow, especially | 


since they are included only for completeness of explanation. Tables necessary for this 
program are included in the example. They are discussed in detail in Section 3. . 


“ety 
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* 
* PROGRAM INITIALIZATION 
* 


START @ 

CSECT 

TNHDSECT XCPIOCP 
TNHDSECT LLT 
RGEQU 

USING TN#PARP,R1 
USING TNHPLINE,R7 
EQU) * 

BALR R2,® 

USING *,R2 

MVI = SWITCH+1,0 


* 


* REQUEST A NETWORK 

* 

NETREQ EQU * 
LA —sR}1, REQPKT 
MVI TN#¥PCMMD,@ 
XC TN#PLINK, TN#PLINK 
MVI TN#PFUNC, TNHPNREQ 
MVC _ TN#PFCPL,=A(NTREQCMP) 
LH = -R3, TIMES 
STH  R3,TN#HPTIME 
CCRCALL (1) 

& 


* REQUEST A LINE 


* 


 LNEREQ1 EQU: * 


LA R1,REQPKT 

MVI TNHPCHNL,2 

MVI TN#PPORT,8 

MVI TNHPS8@P, 1 

MVI TN#PCMMD,@ 

MVI TN#PFUNC, TNHPLREQ 

xc TNHPLINK, TNHPLINK 

LH R3, TIMES 

STH  R3,TN#HPTIME 

MVI - TN#PBLTH+1, 256 

MVC TNHPFCPL,=A(LNREQCMP) 

MVI. TN#PDSPL,3 

MVI TN#PCAID,1 
“—~CCRCALL (1) 





Figure 2-3. Basic User Program Example (Part 1 of 6) 
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* 
* INITIALIZE 


* 

INITLNE EQU 

SWITCH BC 
LA 
MVI 
MVI 
XC 
LK 
STH 
MVC 
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THE LINE - (1) CLEAR THE LINE ADAPTER 


* 


@, SENDMSG 

R1,REQPKT 

TNHPCMMD ,@ 

TNHPFUNC, TN#PFSL+TNHPLACL 
TNHPLINK, TN#PLINK 

R3, TIMES 

R3 , TNHPTIME 

TNHPFCPL ,=ACLACMPL) 


CCRCALL (1) 


* 


* INITIALIZE 

* 

LDPCWw ss EQU 
MVC 
LA 
MVI 
MVI 
MVI 
MVC 
xc 
LH 
STH 
MVC 


THE LINE = (2) LOAD PORT CONTROL WORD 


* 


OUTBUFF , DCT2PCW 
R1,REQPKT 
TN#PCMMD , © 
TN#PFUNC , TN#PFSL+TNHPLB 14 
TN#PBLTH+1,4 

" ‘TN#PBADR ,OUTBUFAD 
TNHPLINK, TN#PLINK 
R3, TIMES 
R3, TNHPTIME 
TNHPFCPL ,=ACLPCWCMPL) 


CCRCALL (1) 


* 
* INITIALIZE 


* 
LDCDT1 EQU 
LA 
MVC 
MVI 
MVI 
MVC 
MVC 
XC 
LH 
STH 
MVC 


THE LINE - (3) LOAD THE CHARACTER DETECT TABLE 


* 


R1,REQPKT 

OUTBUFF ,DCT2CDT 
TNHPCMMD ,@ 

TNHPFUNC, TN#PLCD4 
TNHPBLTH, W256 
TN#PBADR , OUTBUFAD 
TNHPLINK , TNH#PLINK 
R3, TIMES 

R3, TNHPTIME 
TNPFCPL,=AC(LCDTCMPL) 


CCRCALL (1) 


* 


* INITIALIZE 


THE LINE - (4) LOAD CHARACTER INTERPRETATION TABLE 


Figure 2-3. Basic User Program Example (Part 2 of 6) 
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LocIT1 EQU * 
LA R1,REQPKT 
MVC OUTBUFF,DCT2CIT 
MVI TNHPCMMD ,® 
MVI ‘TNHPFUNC, TNHPLCI1 
xc TNHPLINK, TNHPLINK 
MVC TN#PBADR,OUTBUFAD 
MVI TNHPBLTH+1,32 
LH - R3,TIME3 
STH R3,TNHPTIME 
MVC TNHPFCPL,=ACLCITCMPL) 
CCRCALL (1) 
‘* _ 
* INITIALIZE THE LINE = (5) SET DATA TERMINAL 
SETRMRDY EQU) * 
LA R1,REQPKT 
MVI TNHPCMMD,@ 
MVI TNHPFUNC, TN#PFSL+TN#PDOTR 
xc TNHPLINK, TN#PLINK 
MVC TNHPBADR,AFAKEBUF 
LH R3, TIMES 
STH R3, TN#PTIME 








MVC 8 =—- TN#'PFCPL, =ACSDTRCMPL) 
CCRCALL (1) 





* 


* TRANSMIT A MESSAGE 
* 
SENDMSG EQU * 
LA  -R1, OTPTPKT © 
MVI TNHPCMMD,@ 
MVI TN#PFUNC, TN#PSEND+TN#HPFSL 
MVC OUTBUFF ,MSG1 
XC TN#PLINK, TNHPLINK 
LH  -R3, TIMES 
STH R3, TN#PTIME 
MVC TNHPBADR,OUTBUFAD 
MVI ‘ TNHPBLTH+1,80 
MVC TNHPFCPL, =A(SENDCMPL) 
CCRCALL (1) 


* 
* RELEASE THE LINE - (1) ISSUE LINE TURNOFF 


* 


Figure 2~3. Basic User Program Example (Part 3 of 6) 
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LNEREL1 EQU * 
LA R1,REQPKT 


MVI- TNHPCMMD, © 
MVI ‘ TN#PFUNC, TN#PFSL+TNHPIOFF 
XC  TN#PLINK, TN#¥PLINK 

LH  -R3, TIMES 

STH R3,TNHPTIME 

MVC  TN#PFCPL,=ACNOMOPKTS) 
CCRCALL (1) 


* 
* RELEASE THE LINE - (2) ISSUE LINE RELEASE 


* 
LNEREL2 EQU * 
LA  —-R1, REQPKT 
MVI ‘ TN#PCMMD, @ 
MVI ‘TN#PFUNC, TN¥PLREL 
"XC  - TNAPLINK, TN#PLINK 
LH = R3, TIMES 
STH  R3,TNHPTIME 
MVC TN#PFCPL,=ACLRELCMPL) 
CCRCALL (1) 


* 


* RELEASE THE NETWORK 
* 
NETREL1 EQU * 
LA R1,REQPKT 
MVI TNHPCMMD,@ 
MVI ‘TNHPFUNC, TN#PNREL 
xe TNHPLINK , TN#PLINK 
LH R3, TIMES 
STH 3, TNHPTIME - 
MVC TN#PFCPL,=ACNETRLCMP) 
CCRCALL (1) 


* 
* DUMMY COMPLETION ROUTINES 


* 
NTREQCMP EQU * 
B LNEREQ1 
LNREQCMP EQU) * 
B INITLNE 
LACMPL EQU * 
MVI  -SWITCH#1,X'FO! 
B LDPCW 





Figure 2-3. Basic User Program Example (Part 4 of 6) 
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LPCWCMPL * 
LDCDT4 
LCDTCMPL * 
LDCIT1 
LCITCMPL * 
SETRMRDY 
SDTRCMPL s 
SENDMSG 


SENDCMPL i 
LNEREL1 
NOMOPKTS bal 
LNEREL2 
LRELCMPL = : 
NETREL1 
NETRLCMP * 


ENDCPI 
* 





CNOP @,4 


* START CONSTANT AREA 
* 


CNOP 0,8 


REQPKT DS 14F'@! 
INPTPKT DS  14F'@! 
OTPTPKT 14F'@! 
OUTBUFF CL8e 
FAKEBUFF Fre! 
OUTBUFAD AL3(OUTBUFF ) 
AFAKEBUF AL3(FAKEBUFF) 
0,4. 
TIMES H'3! 
W256 X'9100' 
ZEROES X' 990000! 
MSG1 C'FOUR SCORE AND S! 
C'EVEN YEARS AGO 0! 
C'UR FATHERS BROUG' 
C'HT FORTH ON THIS! 
C' CONTINENT...END! . 
CNOP 6,8 





* 
* PORT CONTROL WORD 


* 


DCT2PCW DC X' 86261902 ' 





Figure 2-3. Basic User Program Example (Part 5 of 6) 
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* CHARACTER DETECT TABLE 


* 


DCT2cDT DC 
pc 
Dc 

pe 
Te 
pc 
pc 
oc 
Dc 
oc 
pc 
oc 
pc 
oc 
pc 
pc 
oc 
oc 
Dc 
oc 
Dc 
DC 
pc 
oc 
Dc 
Dc 
pc 
oc 
oc 
Dc 
Dc 


DC. 


* 


* CHARACTER 

* 

DCT2CIT DC 
pc 
oc 
Dc 
pc 
pe 
Dc 
Dc 


X'0012001317001414' 
X' O8OOO9ORO9OR0000' 
X"9014000000141000' 
X'9000001300001400' 
X' OOOOSOORORE90R0' 
X' 9OCOODOODOOOOR0O' 
X' O9B9ORRERECER000' 
X' 99OOCO9R0R000000' 
X' S9OCRGCCDORERCR0' 
X' C9OOSORCGORRR000' 
X' @OOSEDSRR0R00000' 
X' O9OODORR9RC0R000' 
X' O9OOOOOSDOSC0000' 
X' GEGOSOECREECEREO' 
X' OOODERECOCOR—OR' 
X' C9OdOOOCORCCRR00' 
X'9000001300001400' 
X' O9OODOOCOOR900—0' 
X'9014000000000000' 
X' G9OOOROCOROCROC0' 
X'O9OROSOR0R000000' 
X' SOGOOOCCDCDO0R00' 
X' 9000O9O90C0R0000' 
X' GO99EDE0RC0R0R00' 
X' 9990900000 000000' 
X' 9OCOOO909S0R0R00' 
X'9OSOOOO9OO0RR000' 
X'0000000000000000' 
X'9OO0OOCRdCRR0000' 
X' 9OROROOCODEODE—0! 
X' OGOOOSOCOO0R0000' 
X' C0OODED0000ERR—0' 


INTERPRETATION TABLE 


X' 68010000! 
X' 11014806! 
X'41600000' 
X'90004100' 
X'O0000000' 
X'O6000060' 
X'OOOOSOO9! 
X'O9O0000000' 





Figure 2-3. Basic User Program Example (Part 6 of 6) 
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es 


.a{ TN#PFUNC/TN#PFSL) is -set. 
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3. Additional User Program 
Features 


wenn ee Sevedetoceny cn at sii 


3.1. CONTROL PACKET CHAINING 


The physical interface supports both data buffer chaining and message chaining. Data 
buffer chaining is the linking of control packet buffers for input or output of a single 
message. The buffers may be chained through the TN#PLINK field of the control packet 
at the time of CCRCALL execution, or they may be linked one or more at a time. The 
communications physical |/O control system (CPIOCS) will then chain a following control 
packet behind one that is already queued on a particular line. Invalid packet chaining 
links cause unpredictable errors. Message chaining is the same as the linking of data 
_buffers with the exceptions’ that more than one complete message 


4 


For data buffer chaining, the first control packet of a message or function must have 
TN#PFUNC set to TN#PFS (start of message). Output messages must have TN#PFUNC 
set to TN#PFL for the last control packet of a message (end of message}. You must set 
up the first two CPIOCPs before issuing the first CCR call. Failure to do so causes a 
chaining check error. It is also required that all control packets within one message have 

TN#PMUX set to the same channel and SLCA numbers. . 


Whenever the ‘function or buffer of a specified control packet reaches completion, the 
control packet is scheduled back to your program unless TN#PFLGS is set to TN#PCIX 
(buffer completion suppressed), or TN#PESO (error schedule only). If either of these 
flags is set and the condition indicated by the flag is met, the packet is released from 
the active line queue and placed on a delayed queue for the same line. tf the flags are 
not set, CPIOCS checks the completion status. if TN#PRIM=TN#PEND 


' (message/function completion) and TN#PDETL=TN#PBCI (buffer completion), CPIOCS 


breaks the link to the chained control packet and proceeds to check for any control 
packets on the delayed queue. If TN#PRIM=TN#PEND and TN#PDETL=TN#EOM 
(successful) message/function (completion), CPIOCS then checks to see whether any 
other contro! packet is chained to this control packet. If there is, a link is kept intact to 
the next control packet that has TN#PFUNC set to TN#PFS. The last control packet in 
the chain is indicated with TN#PLINK set to O. If the completed control packet has any 
error status in TN#PRIM and TN#PDETL, the chain is kept intact regardless of the 
number of control packets having TN#PFS set. 
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NOTE: 


lf buffer toggling is required, TN=PESO (error schedule only) must not be set in the 
TN#PFLGS field of the CPIOCP because it would prevent the buffer completion interrupt 
from being reported. The line buffer size must be an even multiple of the SLCA buffer 
size specified in TN#PBLTH if using buffer toggling. 


Before .scheduling the completed control packet back to your program, together with 
any chained control packets, CPIOCS checks if there are any packets on the delayed 
queue. If there are, the currently completed packet is chained behind the last packet on 
the delayed queue. Status in the currently completed packet is then moved to the head 
control packet on the delayed queue. The head packet on the delayed queue is now 
scheduled back to your program at the completion address specified by its TN#PFCPL 
field together with all control packets chained to it. 


As an example, good use of message chaining is accomplished when chaining an output 
poll message to the first buffer of an input response. The poll control packet has 
TN#PFLGS set to TN#PESO. The first control packet of the input message does not 
have TN#PFLGS set to TN#¥PESO. If the output poll is successfully issued, your program 
will be notified at the completion address of the output control packet when the first 
input message control packet is complete. This technique saves scheduling your 
program until significant information is available requiring your attention, and it provides 
' for issuance of the input function immediately upon successful completion of the poll. 


To clarify the preceding discussion on data chaining, we'll give a coding example of 
each of the two types, including the special case of chaining output polls to input 
response, and point out the major differences of each. 


For data buffer chaining, let’s take a case where we want to send three buffers chained 
, together to make one complete message: 


Packet Field | Action 
1 TN#PFUNC Set to send data with data chaining first packet 
indicator (TN#PSEND + TN#PFS). 
TN#PLINK Set to address of second control packet. 
2 TN#PFUNC Set to send data (TN#PSEND) (not first packet or 
last packet). 
TN#PLINK Sei to address of third control packet. 
3 TN#PFUNC Set to send data with data chaining last packet 


indicator (TN=PSEND + TN#PFL). 


TNSPLINK Set to zeros. 
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Naturally, all three packets must have the same channel and SLCA number. Control is 
@ returned at the completion address of the first packet, and completion or error status 
will be contained in it. Showing these actions in code we have: 


SENDMSG1 EQU) * 
LA R1,OTPTPKT1 
MVI TNHPCHNL,2 
MVI  TN#PPORT,8 
MVI TN#PS8OP, 1 
MVI TN#PFUNC, TN¥PSEND + TN#PFS 
MVC = TN#PLNKF ,=ACSENDMSG2) 
MVC . TNHPBADR,ATEXT1 
MVI TNHPFLGS, TN#PESO 
MVC TNH#HPBLTH,=H'15! 
MVC =6TNHPFCPL,=ACOUTCMPL) 
LH R3, TIMES 
STH R3,TN#PTIME 


SENDMSG2 EQU * 

LA  =—s- R14, OTPTPKT2 
MVI TNHPCHNL ,2 
MVI . TN#PPORT,8 

’ te: MVI -TN#PS8OP,,1 

@ MVI  TN#PFUNC, TN#PSEND 
MVC = TN#PLNKF , A(SENDMSG3) 
MVC  TN#PBADR, ATEXT2 
MVC = TN#PBLTH,=H'17! 
MVC = TN#PFCPL, =ACOUTCMPL) 
LH = R3, TIMES 
STH R3, TNHPTIME 


SENDMSG3 EQU * 

LA —_—- R14, OTPTPKT3 
MVI  TNHPCHNL,2 
MVI ‘ TN#PPORT,8 
MVI TNHPS8OP, 1 
MVI TNHPFUNC, TN#PSEND + TNHPFL 
MVC ‘ TNHPLNKF,=X' 9090! 
MVC  TNHPBADR, ATEXT3 
MVC  TNHPBLTH,=H'34! 
MVC‘ TNHPFCPL, =ACOUTCMPL) 
LH R3, TIMES 
STH 3, TNHPTIME 

| LA R41, OTPTPKT4 

6 CCRCALL (1) 


(continued) 
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OUTCMPL EQU * completion routine 





EOJ 

OTPTPKT1 DS 14F'O! 

OTPTPKT2 DS 14F'O! 

OTPTPKT3 DS 14F'O! 

ATEXT1 oc AL3(TEXT1) 

' TEXT1 oc C'NOW IS THE TIME' 

ATEXT2 oC AL3(TEXT2) 

TEXT2 oc C'FOR ALL GOOD MEN' 

ATEXT3 oC AL3( TEXTS) 

TEXT3 dc C'TO COME TO THE AID' 
oc C' OF THEIR PARTY' 
END 


As you can see, this has the effect of chaining the data buffers together with one 
service request call. The messages or text shown in the buffer are small for the sake of 
brevity — this type of chaining is normally performed where the message is too large for 
one buffer — therefore, it is usually only part of the overall message. 


. Message chaining, as opposed to data buffer chaining, consists of chaining complete 
“ messages together — still with the use of only one service request call..Let’s use three 
messages again (as opposed to three buffers) to show the differences. 





Packet Field Action 
1 TN#PFUNC Set to send eee message (T RAT SENE + 
TN#PFSL). . 
 TN#PLINK =~ Set to address of Sakene control =o 
TN#PFLGS Set to suppress notification until all messages 
complete (TN#PESO). 
2 TN#PFUNC Set to send complete message (TN#¥PSEND + 
TN#PFSL). 
TN#PLINK Set to address of third control packet. 
TN#PFLGS Set to suppress notification until all messages 
complete (TN#PESO). 
3 TN#PFUNC Set to send complete message (TN#PSEND + 
TN#PFSL). 





TN#PLINK Set to zeros. 











ee ee 
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Again, all three packets must have the same channel and SLCA number. Control and 
status are returned to the first packet. As you can see, the only difference in the coding 
would be to set the function byte to send complete messages. 


Finally, message chaining can be used to perform the special case of chaining an output 
poll to an input response. In this case, the messages are still complete messages; 
however, the output packet uses the TN#PLINK field to chain the input packet address. 
For this special case, the TN#PESO bit is set to suppress notification of successful 
completion until the input packet without this setting has been received. Therefore we 


would have: 
Packet 


1 


Field 


TN#PFUNC 
TN#PFLG 


TN#PLINK 
TN#PFUNC 


TN#PFLG 
TN#PLINK 


Action 


Set to complete output message (TN#PSEND + 
TN#PFSL). 


Suppress notification until input complete 
(TN#PESO). 


Set to address of input packet. 


Set to complete input message (TN#PEDI + 
TN#PFSL). 


Set to zero. 


Set to zero. 


Since a poll is actually an output message with. no text, an example of buffer chaining a 


SENDPOLL EQU 
. LA 
MVI 
MVI 
MVI 
MVI 
MVC 
MVC 
MVI 
MVI 
MVC 
MVC 
MYC 
LH 
STH 
LA 
MVI 
MVI 
MVI 
MVI 


* 


R1 OTPTPKT 
TNHPCHNL ,2 
TNHPPORT,8 
TNHPS8OP, 1 
TNHPFUNC, TN#PSE 
OUTBUFF , POLL 
TNHPLINK,RCVPKT 
TNHPCMMD ,@ 
TN#PFLGS, TN#PES 
TNHPBADR , OUTBUF 
TNHPBLTH, =H'5! 
TNHPFCPL,=ACINP 
R3, TIMES 

R3, TNHPTIME 

R1, INPTPKT 
TN#HPCMMD , © 
TNHPCHNL, 2 
TNHPPORT,8 
TNHPS8OP, 1 


poll to the input response might look like the following: 


Map 


ND + TNHPFSL 


Chain packet address 
Clear command byte 


ie) Suppress until chaining complete 
AD 
UTMSG) 
(continued) 
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MVI TNHPFUNC, TNHPEDI + TNHPFSL 

xc TNHPLINK, TN#PLINK Clear chaining 

MVC TN#HPBADR, INPTBFAD 

MVC TNHPBLTH,=H'256' 

MVC TNHPFCPL,=ACINPUTMSG) 

LH R3, TIMES 

STH R3, TNHPTIME 

LA - R1,OTPTPKT Reload first packet 
CCRCALL (1) 


INPUTMSG EQU * Completion routine 


TIMES oc H'S! 

OTPTPKT DS 14 F'@! 
INPTPKT 0S 14 F'@! 
OUTBUFAD DC AL3 (OUTBUFF ) 
INBUFAD DC AL3CINPTBUFF ) 
OUTBUFF DS CL64 


INPTBUFF DS- CL64 S RSDE 
POLL DC =—_- X "9120507003" O 111T 
H DDDX 


ZEROES OC X'000000' 
END 


Note that the completion address of the first packet is the place in your program where 
control is passed. When control is returned, the logical. status of the last packet (or the 
packet with the error) will overlay that of the first packet. 


3.2. READING THE SLCA WORDS AND TABLES 

Sometimes it may be desirable to know the particular line discipline that is already 
resident on a particular port. Or, for diagnostic purposes, it may be desirable to know 
the conditions that existed both before and after an input/output operation on a port. 
The physical interface of ICAM gives you the capability of obtaining this information 
with the diagnostic commands to: 

m read a port control word; 


m= read a character detect table; and 


2 read a character interpretation table. 
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3.2.1. Reading the Port Control Words 


The READ PORT CONTROL WORD command is a diagnostic command that causes the 
SLCA to transfer the control bytes associated with the addressed SLCA to the 
processor. When it is issued, the 32 bytes associated with the port control word are 
read. 


Therefore, if we allocate space in our program for the port control word information and 
construct a contro! packet with this command, we can look at our control information at 
any time for any port. This may be done both before and after any input or output 
function completion for comparison purposes. To perform this procedure, we would 
first do a network request and line request as described in 2.2 and 2.3. Then, when we 
initialize our line, we perform a read port control word function in our control packet. 
This action is, in effect, the opposite operation of loading the port contro! word 
described in 2.4.2. 


Field Action 
- TN#PFUNC Set to read port control word (TN#PFSL + TN#PRPCW). 


TN#PBLTH Not required, CPIOCS automatically transfers 24 bytes in order 
shown. 


* ‘TN#PBADR Set to address of buffer that is to contain the desired information. | 
These actions can be performed with the following typical coding: 


ROPCW EQU) * 


LA R1,REQPKT Map 

MVI TN#PCMMD ,@ Clear 

MVI TNHPFUNC, TN#PFSL+TNHPRPCW Set to read PCW 

MVC TN#PBADR,APCW , Set buffer address 

xe TNHPLINK , TN#PLINK No chaining 

MVC =o TN#PFCPL,=ACROPCWCMP) Set completion address 


CORCALL (1) 


RDPCWCMP EQU * Completion routine 


In your nonexecutable code, you would allocate 24 bytes with a label of PCW. 


APCW oc AL3( PCW) 
PCW bc 6 F'e! 


UP-9746 . 
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3.2.2. Reading the Character Detect Table 


The READ CHARACTER DETECT TABLE command is a diagnostic command that 
transfers a command-specified 256-byte character detect table to the processor. When 
it is issued, the table words are read sequentially beginning with address 0016 through 
FFis. The command requires that an SLCA number referencing the table be given. (You 
will recall that each SLCA references at least one of the two character detect tables.) 


To perform this function, we would do a network request and line request as described 
in 2.2 and 2.3. When we initialize our line, we would then perform a read character 
detect control table function in our control packet. This action is, in effect, the opposite 
operation of loading the character detect table described in 2.4.3. 


Field 
TN=PFUNC 
TN=PBLTH 


TN=PBADR 


Action 
Set to read character detect table number 1 (TN#PFSL+ TN#RCDn). 
Not required. CPIOCS automatically transfers 256 bytes sequentially. 


Set to address of buffer that is to contain the desired information. 


These actions can be performed with the following typical coding: 


RDCDT1 EQU 
LA 
MVI 
MVI 


MVC 
. xe 
~ MVC 


” . 

R1,REQPKT Map 

TNHPCMMD ,@ Clear 

TNHPFUNC, TNHPFSL+TN#PRCD1 Set to read character detect 
, table no. 1 

“TNHPBADR, ACDT1 

TNHPLINK, TNHPLINK 

TNHPFCPL,=ACRDCD1CMP) 


CCRCALL (1) 


RDCDICMP EQU 


* 


Again, sufficient storage would have to be allocated in your nonexecutable code to hold 
the number of tables you want to read (at 256 bytes per table) either totally or one at a 
time: For one table, we would have merely: 


ACDT1 EQU 
CDT 1 oC 


AL3(CDT1) 
64 FIO! 
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3.2.3. Reading the Character Interpretation Table 


The READ CHARACTER INTERPRETATION TABLE command is a diagnostic command 
that transfers a command-specified 16-word character interpretation table to the 
processor. When it is issued, the table words are read sequentially beginning with word 
0016 and ending with word OFie. The command requires that an SLCA number 
referencing the table be given, since each SLCA references one of the character 
interpretation tables. (See 4.2.1.) 


To perform this function, we would do a network request and line request as described 
in 2.2 and 2.3. When we initialize our line, we would then perform a read character 
interpretation table function in our control packet. This action is, in effect, the opposite 
‘operation of loading the character interpretation table as described in 2.4.4. 


Field Action 


TN#PFUNC Set to read character interpretation table number 1 (TN#PFSL 
+ TN#RCI1). 


TN#PBLTH Not required. CPIOCS automatically transfers 16 words sequentially. 
TN#PBADR_ Set to address of buffer that is to contain the desired information. 
: e -«-These actions can be performed with the following typical coding: | 


ROCIT1 EQU * 

LA R1,REQPKT Map 

MVI TNH#PCMMD,® Clear 

MVI ‘TNHPFUNC, TNHPFSL+TN#PRCI1 Set to read character interpretation 
table no. 1 
MVI TNHPBADR ,ACIT1 
xc TNHPLINK, TNHPLINK 
MVC TNHPFCPL,=ACRDCICMPL) 
CCRCALL (1) 


RDOCICMPL EQU * 


Sufficient storage must be allocated in your nonexecutable code to hold the number of 
tables you desire to read (at 16 words per table). For one table, this would merely be: 


ACIT1 oc AL3(CIT1) 
cITi oc 64 F'@! 
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3.3. READ LINE LINK TABLE 
The read line fink table function transfers the last 16 bytes of the line link table 
pertaining to the port specified to the user program's buffer area. To issue a read line 
Jink table command, the following actions must be performed on the specified fields: 
Field Action 
TN#PMUX = Set byte O (TN#PCHNL) to 02, OD, or OF, depending on your System 
80 model type (see Table A—6). Set byte 1 to the SLCA number and 
byte 2 to the port number. 
TN#PBADR_ Set to the buffer address into which the information is to be read. 
TN#PBLTH Not interpreted. The 16 bytes are transferred regardless of value. 
TN#PFUNC Set to TN#PRLLT. Bits 0 and 1 not interpreted. 
TN#PLINK Set to 0. 


Again, we would load our control packet and map it. To perform the actions, our 
coding might appear as: 











LA R1,REQPKT. Map : ae ee Lf Se ae oe 


MVI = TNHPCHNL,2 : Set to channel 2 
, MVI  TNHPPORT,8 Set to port 8 

MVI TN#PS8OP , 1 
MVI TNHPCMMD , © Clear 
MVI TN#PFUNC, TN#PRLLT Set command 
XC TN#PLINK, TN#PLINK — No chaining 

"MVC | TN#PBADR,LNELNKTB ~ Set buffer address 

- MVC = TN#PFCPL,=ACROLLTCMP) Set completion address 


CCRCALL (1) 


RDLLTCMP EQU) * Completion routine 


After checking our status for good completion, we can look at our data in our input 
buffer. However, using our dummy control section technique, we must take into account 
the fact that the line link table is a work area and only the last 16 bytes are read into 
your user program. If you load a register with the address of the 16-byte area into 
which the line link information is to be read, the value must be modified by 20:6 to be 
used properly as a cover for the DSECT. That is, TN#PLINE is the label of the DSECT, 
but to map the labels on your storage area (arbitrarily named LNELNKTB in the 
example), we would have to load the register with the storage area label and a using 
statement with an address of TN=PLINE+20. This would align the relevant DSECT 
labels with our buffer for the line link table. . 
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Looking at our coding, we could have something like the following: 


LA R7, LNELNKTB 
USING TNHPLINE+2@,R7 


CLC TNHPFLGT, TN#PDOWN Line down 

ia TNHPFLGT, TN#PALLO Line allocated 
ee TNHPFLGT, TN#PAPND Allocation pending 
ae TNHPFLGT, TN#PEON ; EON required 

a TNHPFLGT, TNHPNEP No physical Line 
B 


or we could interrogate any other bytes of our line link table buffer area using the 
relevant DSECT labels. 


3.4. CPIOCS TRACE 


ICAM has a trace facility that saves infenmation at critical points within CPIOCS and user 


“program interface code. 


For details on the ICAM trace facility, see the ICAM utilities user guide, UP-9748 
(current version). 

3.5. AUTOMATIC COMMANDS 

Unless a _ diagnostic user specifies that automatic commands be suppressed 
(TN#PFLGS=TN#PS2F), CPIOCS executes commands automatically in response to the 
following conditions: 

1. a control packet time-out occurs; and 

2. a unit check interrupt occurs. 


CPIOCS does the following: 


w In response to a control packet time-out (TN#PTIME decremented to 0), CPIOCS 
issues a halt-device command. 


@ In response to an error interrupt, a sense command is issued. All sense bytes are 
placed in the CPIOCP. 


Whenever there is an outstanding attention condition for a line, CPIOCS takes the next 
control packet you issue and forces the sending of the sense command. This is done to 
fulfil an SLCA requirement that a sense command be issued following detection of an 
unsolicited status. 
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3.6. CANCEL CONDITIONS 


There are three error conditions for which user program interface code will cancel the 
user program following execution of a CCRCALL. The first condition is when register 1 
or the address in TN#PLINK of any chained control packet does not specify a full-word 
boundary for the control packet address. The second condition is when register 1 or 
the address in TN#PLINK of any chained control packet indicates that the entire control 
packet is not within the user program boundary. The third condition is when there is no 
available task identity. Under this condition, TN#PRIM is set to TN#PROGE, and 
TN#PDETL is set to TN#PMNCE. Refer to the OS/3 system messages 
programmer/operator reference, UP-8076 (current version) for a listing of ICAM cancel 
identification codes. 
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4. Single Line Communications 
Adapter Subsystem _ 


4.1. GENERAL 


The single line communications adapter (SLCA) is a microprocessor communications 
controller that coordinates data transfer, status, and commands between the central 
processor and remote devices via communications lines. In the basic Systern 80 Models 
3-6, up to two SLCAs are supported. With a single input/output microprocessor 
attached, Models 3-6 support one to eight SLCAs and Model 8 supports up to 14 
SLCAs (Figure 4—1). With a dual input/output microprocessor attached, Model 8 
supports up to 28 SLCAs. An IOMP is connected to the SLCAs via the multiple line 
communications multiplexer (MLCM), also known as the communications multiplexer 
ae «channel. For a more detailed description of the SLCA, see Section 3 of the System 80 

© IOMP programmer reference, UP-8909. 


_ MAIN STORAGE 
PROCESSOR 





i} eee 1—14 eos O 
SLCAs 


*Shared direct memory access channel (device channel) 


Figure 4-1. System 80:-Mode! 8 with Single input/Output Microprocessor 
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' The SLCAs can be configured to support half-duplex or full-duplex communications 
lines. Logic functions can be dynamically configured by down-line loading the SLCAs 
random access memory (RAM) by ICAM. The RAM can be loaded by ICAM and 
configured to operate in the basic read only memory function, or according to one of 
the following preset features (Table 4—1): 


ws Communications multiplexer module synchronous mode 

= | Communications multiplexer module asynchronous mode 

a Universal data link control (UDLC) mode 

In the communications physical interface, you must construct your own tables of logic 


functions in an ICAM user program and load them into the read only memory via your 
user program. 


Table 4—1. Single Line Communications Adapters 


Posen Transm Half Duplex (HD) “al Microcod: 
Spied Rate (bits/s) Full Duplex (FD) Name oa 


pa7ee-o2 

























" 2788-03 










F2788-03 9600 Syne Byte 
; 9600 


-F2798-00 | RS-232 . 19200. 
: * 9600 

F2799-00 9600 Syne 
4800 

F2799-01 MIL-STD-188 9600 Asyne 
4800 

F2986-05 | CCITT V.35 56000 Syne 
56000 





raeewo [comrvae | wooo | [oe [ow] we | oe 
NOTES 


1. Any standard synchronous byte protocol, e.g., UNISCOPE, BSC, 1004, NTR, or remote workstation 

2. Handles any standard bit-oriented protocol, e.g., X.25 on UDLC ABM. 

3. Any standard asynchronous protocol, e.g., UNISCOPE display terminal, teletypewriter, DCT 500, UTS 10 | 

4. The microcode name is actually eight characters. The first four specify the microcode name, the next two specify the 


release version, and the last two are zeros; for example, CMM1FO0OO0. The release version is supplied in the software 
release description (SRD) for each release. : 


MIL-STD-188 9600. hail : 
4800 
F2788-04 | MIL-STD-188 9600 Byte 
9600 ; 
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4.2. CONSTRUCTING THE SLCA WORDS AND TABLES 


As discussed in 2.4, each port in the SLCA requires a port control word, a control 
character detect table, and a control character interpretation table. A table of each type 
is allocated in the SLCA. One of the functions of the port control word is to reference 
one of the character detect and character interpretation tables. These tables are 
constructed to detect and interpret the control characters necessary for the particular 
line discipline you wish to support. At the physical level interface, you must construct 
these tables within your own user program. 


In the following sections, we'll discuss how to construct these words and tables from 
listings of line discipline common characteristics. These listings are shown within the 
text as we proceed to build our words and tables. Section 5 contains table summaries 
of the initialization parameters created from these lists for currently supported terminals. 
Therefore, we'll first discuss how to generate the words and tables from the 
characteristics for the DCT 2000, since this was the terminal used in our example in 
2.4. Then we'll show how the tables of initialization parameters may also be used to 
directly code the control tables when you are using ICAM-supported terminals. In this 
case, you will see that the tables arrived at by either method are identical. 


4.2.1. How to Construct a Port Control Word 


_A port control word consists of four port control bytes that give specific information to 
the SLCA. Its basic format is: 





where: 

byte 1 
Contains synchronous/asynchronous characteristics. 

byte 2 
Indicates the character detect table to be jaea and contains character length 
and asynchronous line speed, if applicable. 

byte 3 
Indicates the character interpretation table to be used, the start character for 
BCC accumulation, and parity type. 

byte 4 


Concerns synchronous/asynchronous selection and timing values and ranges. 
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. 


Figure 4-2 shows byte 1 in more detail. . i 





o 12 3 4 &§ 6 7 


COMMAND FUNCTIONS (MUST BE ZERO) 
MODIFIERS (MUST BE ZERO) 
CHARACTERISTICS 


Asynchronous Operstion 





ot Characteristic 

x Oo input (specific start characters) invalid® 

x 1 tnput (any nonsync start) Output (1-unit interval stop element) 

Oo xX Output (2 pads + 2 syncs) Output (1-1/2-unit interval stop elements) 
1x Output (4 synes) Output (2-unit interval stop elements) 


* Results in program-aiert sense and unit-check sense. 


oF NOTE: 





x indicates a “don’t care” bit. 
. Figure 4—2. Byte 7 of Port Control Word 
Therefore, if, for example, our terminal were a synchronous operation with four sync 


characters on output, and assuming zeros whenever a bit setting is not specified; we 
_ would have: a: . 





4 SYNC 
CHARACTERS 
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Figure 4-3 shows the format and characteristics for byte 2. Table 4—2 gives 
asynchronous lines speeds. 


CHARACTER DETECT CHARACTER ASYNCHRONOUS 
TABLE SELECT (ALWAYS 00 LENGTH LINE SPEED (Table 4—2) 
FOR SYSTEM 8&0) : 










Character Length 
(exctuding parity bit) 


5 bits per character 


6 bits per character 





7 bits per character 


8 bits per character 


Figure 4—3. Byte 2 of Port Control Word 


"Table 4-2. Asynchronous Line Speeds 


Not used (invaiid °) 
50 


75 


*Results in program-aiert-sense and unit-check status 
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First, we specify character detect table 1 and assume our terminal needs 7-bit character ; 
length. The second byte of our port control word would now look like: & 










= X‘20° _ 


7" _ NOT ASYNCHRONOUS - 
™ THEREFORE, ASSUME ZERO. - 


7-BIT be cies ete 





> CHARACTER DETECT TABLE 1 


Figure 4—4 shows the format and characteristics for byte 3 and Table 4-3 gives its 
parity functions. 






PARITY FUNCTIONS (See Tabie 4~3.) 
INCLUDE/EXCLUDE START CHARACTER 


CHARACTER INTERPRETATION TABLET 
(ALWAYS 00) 


_——— — 





Figure 44, Byte 3 of Port Control Word 
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Table 4-3. Parity Functions for Port Control Word Byte 3 


CTMC/DCS compatible 
CTMC/OCS compatible 


CTMC/DCS compatible 
CTMC/DCS compatibie | 
ANS! async standard 


NTR/ 1004 (synchronous) 
1004 (DLT-1 or DLT-3) 
ANSI sync standard 

U300 (synchronous) 

BSC ASCII nontransparent | 


iene 


BSC ASCII transparent 


> 


BSC EBCDIC or 6-bit code 


CcrrT 





| Selectable CRC 


* Invalid in asynchronous mode 
t Even in asynchronous mode 


tt Odd in asynchronous mode 


NOTES (apply to synchronous mode only): 


1. CRC 1: x™© + x18 + x2 + 1 (CRC-16) 
CRC 2: x6 + xt2 + x5 + 1 (CCITT) 
CRC 3: 16-bit strap selected (special order) 
CRC 4: x12 + x19 + x3 + x2 + x + 1 (CRC-12} 


2. When parity function 11002 is used, 7-bit character size must be specified. When parity 
function 11012 is used, 6-bit or 8-bit character size must be specified. When parity function 
11102 is used, 8-bit character size must be specified. 


Next, we must use character interpretation table 1. For our discipline, we want to 
include the start character in the block check character count (BCC) and we want ANSI 
Standard parity, which means even longitudinal redundancy character (LRC) and odd 
vertical redundancy check (VRC). 
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Going to dur tables and selecting the relevant settings, we have for byte 3: 


0 12 3 4 5 6 7 






= X‘19" 
. CT ee 
_ See STANDARD 
INCLUDE START CHARACTER 


CHARACTER DETECT TABLE 1 
"oer mmm" (ALWAYS 00 FOR AN SLCA) 





Finally, Figure 4—5 shows port control byte 4. Table 4—4 gives high and low elapsed 


time ranges. 


oO 423 4 5 6 7 


TIMER RANGE (BIT 7 DETERMINES HIGH 
RANGE WHEN SET AND LOW RANGE 
WHEN ZERO.) 


SYNC/ASYNC 
NOT USED 


SYNC/ASYNC ~| 


Synchronous/Asynchronous Function 









_ Asynchronous transmission is specified 
0] Synchronous transmission is specified 


(See Table 4—4.) 


Figure 4~5. Byte 4 of Port Control Word 





To get the data placed in the SLCA buffer when a CPIOCP input time-out occurs, you 


must specify a line procedure timer value. 
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Table 4—4. High and Low Elapsed Time Ranges 


High Range* 





* For this timer range, the timer will reset and continue timing when a SYN character is sent or received in addition to 
those reset conditions previously discussed. 


So, for this byte we'll select synchronous transmission, and, for the sake of simplicity, 
we'll not use the timer. Therefore, we have merely: 


0123 4567 





or 
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4-10 





Summing it all up, our port control word looks like: 


o 12 3 4 5 6 7 0123 4 5 6 7 0 12 3 4 5 6 7 0 


: — 


sana 


4 SYNC 


CHARACTERS 






Thus, we now add a label and place this word in the nonexecutable portion of our code 
as: 


DCT2PCW 


~ This word is placed in our output buffer at line initialization time with: 


=——— 


7-BIT CHAR. START CHAR. 
LENGTH IN LRC 


_| 







o 00 0 


(: 
: 


12 3 4 5 6 


_ SYNCHRONOUS 
LINE 


USE CHARACTER — USE CHARACTER ODD VRC PLUS 
DETECT TABLE 1 INTERPRETATION EVEN LRC 
TABLE 1 (ANS! SYNC 
STANDARD) 


oc 


MVC 






X 186201902! 


OUTBUFF ,OCT2PCW 


The port control word can then be loaded as described in 2.4.2. 


feos a 








If you are using a standard remote device ‘handler (that is, a handler written for a device 
currently supported by ICAM), the tables in Section 5 can be used directly to construct 
your port control word. Again, using the DCT 2000 as our exampie, Table 5—7 shows 


the following: 











Vaiue 

(binary) 
Pf et | 10 | rer scarce on oe 
Pe [ea [10 | enti tenner man 


3 : 1 Include start character in LRC 
4-7 1001 Odd VRC plus even LRC 
ae 
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Coding this directly gives us: 


z | 
-. BYTE 1 BYTE 2 : BYTE 3 BYTE 4 
1 ae, | 3.4 5 6 7 o 1 ae ey 3 4 5 6 7 o 12 3 4 5 6 1 Peon | 3.94 5 6 7 


and, assuming all zeros for any bits not specified, we would again have X‘80201902’ — 
the same value as obtained from our previous characteristic tables for our hypothetical 
case. Thus, it is easier to use the tables already constructed for us when we have one 
of the supported devices; we must use the characteristics table when we have a unique 
device. 


4.2.2. How to Construct a Character Detect Table 
The character detect table is used to detect single or multiple function characters. It 
uses the low-order 5 bits of a byte to signify the particular function. When bit 3 is not 


set, it signifies a single function; when it is set, it signifies a multiple function. For 
instance: 





sm 


SUPPRESS CHARACTER 





SINGLE FUNCTION . 


SEE CHARACTER INTERPRETATION TABLE WORD 3 


MULTIPLE FUNCTION 


rene 
owe Se ae 
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Table 4-5 gives the functions in effect when bit 3 is zero and the detected character jis 


preceded by a DLE character. 


Table 4~5. CD Table Functions When Preceded by DLE Character 


END-CHARACTER 


Produces no contro! function 


Produces no contro! function 


Stops input data and causes DEVICE END status to 
be set. Ends two character sequences, DLE O and 
DLE NAK. This function is active only if a BCC is 
not being accumulated when this character is 
detected. 


Produces no control function 

Produces no contro! function 

Causes UNIT CHECK status and the MONITOR 
sense bit to be set. Active only after detection of a 
START CHARACTER and before detection of an 
END CHARACTER. Input or output data flow stops 
until a new command is received. 

Produces no control function 


Produces no control function 











Table 4-6. gives the functions in effect when bit 3: is zero and the detected character is 


not preceded by a DLE character. 


Table 4-6. CO Table Functions When Not Preceded by DLE Character (Part 1 of 2) 


NO-OP 


SUPPRESS CHARACTER 


START-END 


Produces no contro! function 
Produces no control function 


Produces no contro! function 


The character is suppressed and not transferred to 


the processor. Active on input only. 


Produces both START CHARACTER and END 
CHARACTER functions and is used for single 
character replies, for example, ACK and NAK. This 
function is active only if a BCC is not being 
accumulated when this character is detected. 


Generates DEVICE END status. 








UP-9746 SPERRY 08/3 4-13. 
, ICAM COMMUNICATIONS PHYSICAL INTERFACE (CPI) 


Table 4-6. CD Tabie Functions When Not Preceded by DLE Character (Part 2 of 2) 


Bit Position 

Designation 
.34567 SS Ee eee ee 
0 


MONITOR Causes UNIT CHECK status and the MONITOR 
sense bit to be set. Active only after 
detection of ea START CHARACTER and 
before detection of an END CHARACTER. 
Input or output data flow stops until a new 
command is received. Normally used to 
monitor output text for illegal text characters 












Produces no contro! function 


Produces no control function 


When bit 3 is set for multiple functions, the second half-byte now refers to a specific 
word of a character interpretation table to supply the additional information. Table 4-7 
describes the format in this case. 


Table 4—7. CD Table Codes Accessing the CI! Table 





SYN*® — See word 0 (CI table access for asynchronous mode}. 


DLE’ — See word 1. 
Cl table access only — See word 2. 
Cl table access only ~ See word 3. 
_ Cl table access only — See word 4. 
Cl table access only - See word 5. 
Cl table access only - See word 6. 
EOT® — See word 7. 
Cl table access only — See word 8. 
Cl table access only = See word 9. 
Ci table access only — See word 10. 
Cl table access only ~- See word 11. 
Cl table access only ~ See word 12. 
Cl table access only — See word 13. 


@ Cl table access only - See word 14. 





Cl table access only — See word 15. 


* These codes access the a able and also produce hardwired functions; 
therefore, they must be used only for the indicated contro! character. An input 
DLE EOT sequence always causes a disconnection when the 11'€ and 17°§ 
codes appear in the Cl table. 
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Armed with this format information, as each input or output character is received, it is 
used as an address to access the character detect table. The control code is read from 
the table and the relevant functions are produced. Since either parity may be used, this 
fact must be taken into consideration when constructing the table. That is, output 
characters address a table before a parity bit is inserted (when used). Input characters 
are used to address the table before the parity bit is stripped. 


To make it easier for you to see an example of this, the control code ASCII hexadecimal 
values are shown here with their functions. 





In constructing a table then, let’s assume we need the codes checked, which in reality © 

are the codes required for the DCT 2000. We also require that, on input, we can have 

only an ETX, ACK, and DC1. Since input means before parity is stripped, on input these 

characters would look like 83, 86,.and 91, respectively, since the most ww bit 
would be set. 


- As we mentioned, the character itself is used as-an address to access the table; 
therefore, the table must be constructed similar to a translate table (Figure 4—6). 
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00 01 02 03 04 05 06 07 | 08 09 OA OB OC OD OE OF 
& , 00/00 12 00 13 17 00 14 14 | 00 00 00 00 00 00 00 00 
10}00 14 00 00 00 14 10 00 | 00 03 00 00 00 00 00 00 
20 100 00 
30 }00 
40 joo 
50 {00 
60 |00 
70 100 
80 J00 00 00 13 00 00 14 00} 00 00 00 00 00 00 00 
90100 14 00 00 00 00 00 00} 00 00 00 00 00 00 00 
A0|00 
80/00 
cojoo 
D0|00 


e 2. E0|00 - 


FO 100 


i 
| 
| 


88s 888 8 8 8 8 8 8 8 


Figure 4-6. Character Detect Table 


This tells us that, when an SOH (X‘01’) is detected, the SLCA will go to location X‘01' 
in our character detect table to find the functions to be executed. In this case, the 
function is a X'12’. Since bit 3 is set in a X‘12’, we know from our previous discussion 
that it signifies a multiple function, which is contained in word 2 of the relevant 
character interpretation table. An ETX (X‘03’) would access location X‘O3’ of our table, 
which in turn signifies a multiple function contained in word 3 of a_ character 
interpretation table. 
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‘Coding our table as shown then, assuming all locations not 
the table a label, we have: 


DCT2CDT oC 


Again, as in the port control word, if you are using a standard supported device, such 
as the DCT 2000, the relevant table in Section 5 can be used directly to construct your 


character detect table. For the DCT 2000, the following initialization parameters are 


summarized: 


. 


X'06 
X'00 
X*60 
X'0@ 
X'0O 
X'0@ 
X'06 
X'@@ 
X'00 
X'0@ 
X'00 
X'00 
X'O0 
X'00 
X'0@ 
X'00 





NOTES: 


@® These characters occur curing input only (before parity is stripped 


12 
14 
oe 
00 
00 
eo 
00 
00 
00 
14 
oo 
ee 
) 
00 
00 
Cr) 


00 
00 
o¢ 
00 
00 
0 
66 
eo 
oe 
00 
00 
00 
00 
00 
CT) 
00 


13 
ee 
oe 
00 
0@ 
00 
oe 
00 
13 
oe 
00 
00 
00 
oo 
00 
oe 


17 
oe 
00 
00 
ee 
oo 


from the character). 


oo 
14 
00 
00 
oe 
00 
0 
oe 
60 
oe 
0o 
00 
oo 
oe 
oe 
00 


14 
16 
oe 
oe 
ee 
ee 
oe 
oe 
14 
oo 
oe 
00 
oo 
oo 
00 
oo 


14 
oe 
00 
00 
00 
oe 
0@ 
oe 
0@ 
00 
oe 
oo 
oe 
oe 
00 
0e 


eo 
oe 
oe 
oe 
oe 
06 
oe 
oe 
oe 
oe 
00 
00 
0e 
oe 
oe 
oe 


00 


63 
ee 
oo 
oe 
00 
oe 
00 
oe 
00 
00 
oe 
oe 
00 
oe 
00 


Meaning of Setting 


00 
ee 
ee 
oe 
vd) 
00 
60 
oe 
oe 
Oe 
oo 
ee 
vr) 
00 
vy) 
00 


eo 
60 
06 
1) 
oe 
oe 
06 
ee 
08 
60 
oo 
oe 
oT) 
0 
00 
00 


used to be zeros, and giving 


00 
06 
oo 
ee 
00 
00 
00 
00 
00 
00 
00 
00 
oo 
00 
o@ 
00 


‘See Cl word 2 
See‘ C! word 3 
See Cl word 7 
See Cl word 4 
See Cl word 4 
See Ci word 4 
See Cl word 4 
See Cl word 0 
Suppress character (input) 
See Ci word 3 
See Cl word 4 
See Ci word 4 


oo 
60 
ee 
00 
eo 
oe 
CT) 
6e 
ee 
60 
oe 
00 
oo 
oe 
ee 
00 


00 
00 
00 
iT) 
00 
00 
00 
00 
06 
00 
00 
00 
00 
oe 
00 
00 


@ All other CD table settings will be zero, implying data characters. 


ee' 
o0' 
ee! 
60' 
@e' 
¢e' 
@e' 
ee! 
@o' 
60' 


00-OF 
1O-1F 
20-2F 
30-3F 
40-4F 
50-5F 
60-6F 
70-7F 
88-8F 


90-98. 


OO' “AO—AF 


BO-BF 
CO-CF 
DO-DF 
E@-EF 
FO-FF 


4-16 








} 
e 





° 
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With this method, the value contained in the CD table setting column is placed in our 
@ coded table at the location corresponding to the value in the ASCII character column: 


location O01 = 12 


location 03 = 13 e 
location 04 = 17 


location 91 = 14 


Assuming all locations other than those specified to be zero, you would derive the same 
table that was constructed by our previous method. Thus, it is easier to use the tables 
already constructed for us when we have one of the supported devices, but we must 
construct our own from scratch when we have a unique device. 


As before, we place our table in the nonexecutable portion of our program and move it 
into our output buffer at line initialization time with: 


MVC =©OUTBUFF ,DCT2CDT 


The character detect table can then be loaded as described in 2.4.3. 


e 4.2.3. How to Construct a Character Interpretation Table 


The character interpretation table is composed of sixteen 12-bit words. These words 
are accessed by the character detect table to support multiple functions. Each bit of a 
character interpretation table word produces a single function when set. Thus, each 
word can cause multiple functions to be performed. 


The format of a Cl table word is: 


@123 4567 @123 4567 


eee! en AO eee 
¢t 


ALWAYS 
ZEROS 
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"where the bit settings cause the functions to be performed as given in Table 4—8. 


Table 4~8. Character interpretation Table Functions (Part 1 of 2) 


INTERMEDIATE 
END CHARACTER 


END CHARACTER 


START BCC 


SUPPRESS CHARACTER 


Not used 


MONITOR 


START CHARACTER 


This bit is normally used to detect an ITB 
character. During an input, the following BCC is 
checked and results are stored until the 
end-character code (ETB or ETX) is detected, at 
which time the appropriate status and sense bits 
are set. No automstic look-for-sync function 
occurs, and input data fiow is not stopped 
regardiess of the BCC checking results. A new BCC 
accumulation is started and includes the next 
non-SYN character received. During an output, 
detection of the ITB character causes transmission 
of BCC. Output data flow is not stopped and a new 
BCC is started on the next character received from 
the MLCM to be an output. 


Channel-end, device-end status is set. If applicable, 
the following BCC is checked. Automatic 
look-for-syne function commences after the BCC is 
received. This bit stops input or output data flow 
until a new command is received. 


Must be preceded by a start character. Stops input 
data flow and sets channe!-end, device-end, as well 
as unit-check status bits. Also sets abort sense bit. 
This bit is active onty on input. Automatic 
look-for-sync function occurs immediately. 


Starts BCC accumulation, but ignored = if 
accumulation has already been started. This bit is 
active on input as weil as output. 


Character is not transferred to the MLCM by the 
SLCA. This bit is active on input only. The 
character is included in the BCC unless bit 11 is 
also set to 1. 


Set to 0. 


Causes unit-check status and monitor sense bits to 
be set. This bit is active only on output. 


First specific non-SYN character that starts input 
data. If a start character has already been detected, 





-this bit has no effect. 
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Table 4-8. Character interpretation Table Functions (Part 2 of 2) 
ee 


Not used 





EXCLUDE _ This character and the preceding DLE character are 

DLE CHARACTER — excluded from the BCC accumulation when they 
occur after a start character. This function is active 
only if the detected character was preceded by a 
DLE character. (These characters are used in ANSI 
comtro! procedures for ernbedding acknowledgment 
in the text). Active onty when LRC type parity 
function is specified. 

RESET TRANSPARENT Places SLCA port into nontransparent mode. This 
bit is used only for input. This function is active 
only if the detected character was preceded by a 


DLE character. Active only when set in conjunction 
with end (bi 1) or ITB (bit 0) 


SET TRANSPARENT Places SLCA port into transparent mode. This bit is 
active for input as well as output. This function is 
active only if the detected character was preceded 
by a DLE character. 


SUPPRESS BCC The accumulsted BCC is suppressed for this 
Ses | character. This bit is not active in transparent 

mode. The character is transferred to the MLCM 

unless bit 4 aiso is set to 1. 


* Bits 1 and 6 both set to 1 in the same Ci word, upon detection of the control character in the : 
data stream, would result in performance of the functions specified for bit 0, but functions 
specified individually for bits 1 and 6 would be ignored by the SLCA. 


To illustrate the use of this table, we might want to have the functions of suppressing 
the block character check count and also suppressing the character on input. Using our 
table and setting the relevant bits we would have: 


BYTE 0 BYTE 1 


0123 4567 0123 4567 


o0ee 1000/000e/e0e 1|=x>0801 
| eer 


ALWAYS ZEROS 
SUPPRESS CHARACTER 
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‘Considering the DCT 2000 discipline in our example, let’s make a list of some of the 
multiple functions required: 





1. A SYN function, when hardwired, requires an additional suppress character and 
suppress BCC. 


2. An SOH requires start character, start BCC, and suppress BCC functions. 
3. An ETX requires a suppress character and end character functions. 

4. An EOT requires a start character function. 

5. The BEL, DC1, NAK, and ACK require an additional start eharactes function. 


Putting all these requirements into our character interpretation table, we have the table 
* shown in Figure 4—7. = 


0123 4567 4567 HEX. 


FUNCTION 








Figure 4-7. Character Interpretation Table 


WORD @ 0000 1000 200e €001=X'9801' (SYN) 
. SUPPRESS CHARACTER surpndas Bcc 
; 1 0000 e000 0000 0000=x'e0e0: 
2 0001 e001 e000 0001=X'1101' (SoH 
START BCC START CHARACTER SUPPRESS BCC 
3B | o100- 1000 e000. 00 00=x'4800' ETH 
4 0100 9007 o00e @@@@=X'4100" (BELDCI) 
: ; (NAK,ACK) > 
END CHARACTER START CHARACTER 
5 0000 0000 0000 0000=x'e000' 
6 0000 o0ee 2000 0000=X'9e00! 
z 0100 0001 9000 0000=X'4100' COT 
END CHARACTER START CHARACTER 
8-15 | 6000 2000 e000 0000 =X'ope0! 
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Putting this all together, and adding a label, we have: 


DCT2CIT DC 
pc 
oc 
bc 
DC 
oc 
oc 
oc 
oc 
pC 
oc 
DC 
oc 
oc 
oc 
pc 


X'0801' 
X'0000! 
X'1101! 
X'4800' 
X'4100' 
X'6600' 
X'OO00' 
X'4100' 
X'9000' 
X'0060' 
X'90e0' 
X'0000' 
X'@009! 
X'9O00! 
X'Q@O0¢! 
X'0000! 
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Once the character interpretation table is complete, we may then go back to the 


character detect table and fill in the word numbers that we need to fulfill our list of 


requirements. For example, our first requirement was that an SOH required the additional 
., functions of start of data, start BCC, and suppress BCC. Therefore, we can now see 
& why we used a X‘12’ in location 01 of the character detect table. When an SOH is 
detected, the SLCA accesses location 01 of the character detect table and finds the 
value X'12°: This value is determined to mean 





TABLE WORD 2 
MULTIPLE FUNCTION 


Summing the functions then, we have: 


SOH, start character, start BCC, suppress BCC 


which is what we require. 


SEE CHARACTER INTERPRETATION 
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-Again, going to Section 5, we find that the initialization parameters for all the currently : 
supported devices are contained in tabular form. lf we are using a supported device, we @ 
may use these tables to directly code our character interpretation table. Using our DCT 
2000 example, we have the following: 


Cl Table 
Setting® 
(hex) 


SYN: character (hardwired function), suppress character, suppress BCC 
Not used 

Start characters plus start BCC plus suppress BCC 

Suppress character plus end character 

Start character plus end character 

Not used 

Not used 


Start character plus end character 





“All other Ci table settings will be zero. 


As you can see, this is identical to the table arrived at by our previous method. It is just 
a table preconstructed for us to make it easier to create our coding tables when using 
supported devices. If we are using unique devices, we must construct our tables from 
the first method, whereby we constructed our words from the character interpretation 
-table bit settings. As before, once our table is coded, we place it in the nonexecutable 
‘portion of our program. At line initialization time, we then place it in our output buffer - 
via 


MVC OUTBUFF, DCT2CIT 


before performing the load character interpretation function. The character interpretation 
table can then be loaded as described in 2.4.4. 
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5. SLCA Table Initialization 


5.1. GENERAL 


The initialization parameters for the SLCA that are pertinent to the terminal handlers are 
listed in the following tables. The definitions in each paragraph are the numeric values to 
be preset into the control character detect table, control character interpretation table, 
and port control word for each terminal currently supported by SPERRY software. 


5.2. DCT 500 SERIES/TELETYPE* TELETYPEWRITER REMOTE 
DEVICE HANDLER 


The. DCT 500 series /TELETYPE Teletypewriter rernote device handler provides the 
- initialization parameters listed in Tables 5—1 through 5—5. 


Table 5~1. DCT 500 Series/TELETYPE Teletypewriter ASC Control Character Detect Table 


Suppress input character 


See Cl word 5 


See Cl word 8 
See Cl word 9 
See Ci word 1 
See Cl word 10 


Suppress input character 





NOTES: 
r @ Depending upon the parity of the characters transmitted by the terminal, it 
6 may be necessary to have duplicate settings for both parities of the 
characters; for example, an odd-parity OCT 500 must have the setting 
15.6 for both O31 and 83:46. 
@ All other cD table settings will be zero, implying data characters. 


*Trademark of Teletype Corporation 
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Table 5-2. OCT 500 Series/TELETYPE Teletrypewriter ASCII Control Character Interpretation Table a 





F 


Setting 
(hexadecimal) 


.Meaning of Setting 


DLE EOT disconnects line 
Not used 

Not used 

Not used 

Not used 

End character 

Not used 

Not used 

End character 


End character 





Suppress input character 


H-LTRS ends input@) 





Gd) All other CD table settings will be zero, implying data characters. 


The table assumes that the sequence H-LTRS will be chosen by the user 
to signal end of input. 
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Table 5-4. DCT 500 Series/TELETYPE Teletypewnter Baudot Control Character Interpretation Table 


Setting ; j 
[ete | (hexadecimal) Meaning of Setting 


0 - Not used 
1 0000 Set DLE 
2 

through 
15 - Not used 


Table 5~5. DCT 500 Series/TELETYPE Teletypewriter Port Control Word (Part 1 of 2) 





Two-unit mervai stop elemem (for 110 bps operation) 


One-unit interval stop element (for ail other 
transmission rates) 


For Baudot terminals 


er | ae For ASCH terminais 
® Not used finvaiid®) 

50 bps 

75 ops 

110 bps 

134 bps 

150 bps 

300 bps 

600 bps 

900 bps _. 

1200 bps 

1800 bps 

2400 bps 

3600 bps 

4800 bps 


e 7200 bps 


9600 bps 





*Permitted values 
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= : , = 
Table 5-5. DCT 500 Series/TELETYPE Teletypewriter Port Control Word (Part 2 of 2) 


No parity checking’ 









Odd parity® 


Even parity’ 






Asynchronous transmission ~ 





* Permitted values F oh ies 


5.3. DCT 2000 REMOTE DEVICE HANDLER 


‘The initialization parameters provided in the DCT 2000 remote device handler for the 
control character tables and port control word are mates in Tables 5—6 through 5-8. 


Table 5-6. DCT 2000 Cantal Charade! Detect Table 





See Ci word 3 

See Cl word 7 

re 4 , See Ci word 4 
| 14 See Cl word 4 


See Cl word 4 


See Ci word 4 
See Cl word 0 
Suppress character (input) 
See Cl word 3 
See Cl word 4 


See Ci word 4 





NOTES: 


@ . These characters occur during input only (before parity is stripped from the 
character). 





@) All other CD table settings will be zero, implying data characters. 
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Table 5-7. DCT 2000 Control Character interpretation Table 


Cl Tabie 
Setting* Meaning of Setting 
(hexadecimal) 

SYN character (hardwired function), suppress character, suppress BCC 
Not used 
Start character plus start BCC plus suppress BCC 
Suppress character plus end character 
Start character plus end character 
Not used 
Not used 


Start character pius end character 


Poa SVN chaearconeupe 
Seven-bit character length 


include start character in LAC 


Odd VRC pius even LRC 


Synchronous line 





5.4. 1004/9200/9300 REMOTE DEVICE HANDLER 


Tables 5-9 through 5—11 list initialization parameters provided in the 1004/9200/9300 
remote device handler for the control character tables and port control word. The same 
initialization parameters are used for the 1004 slave mode handler. 
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Table 5-9. 1004/9200/9300 Control Character Detect Table - 
DLT-1 and OLT-3 Boards 





CO Tabi 
Setting?) Meaning of Setting 


SYN character, see Cl word 0 
EOM on input, see Cl word 3 


EOM on output, see Cl word 3 





@) The SOM on input is 40.6, which is considered to be a data character 
because of its odd parity. The port control word is set to start input and 
start BCC on the first nonsynchronous input character. 


(2) All other CD table settings will be zero, implying data character. 


Table 5~10. 1004/9200/9300 Control Character interpretation Table 








on : i ; , SYN character, suppress data character on input 





Not used = 
Not used 


Suppress 8CC, end character, suppress 
character on input 


Not used 








‘ 


a 
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Table 5-11. 1004/9200/9300 Port Contrat Word 


Four SYN characters on 
Output, start input on first 
nonsync 


Six-bit character length 


Start character included in LRC 
Parity option 8: 


Data = odd parity 
Control characters = 

_ even parity 
LRC = even 
LRC parity = even (not 
checked on input) . 


Line procedure timer value as 
required (O's if not used) 
Synchronous 

Line procedure timer range as 
required 





e 


5:5. UNISCOPE 100/UNISCOPE 200/DCT 1000/UTS 400/UTS 4000 
REMOTE DEVICE HANDLER 


Tables 5-12 through 5-14 list the initialization parameters provided in the UNISCOPE 
100/UNISCOPE 200/DCT 1000/UTS 400/UTS 4000 remote device handler for the 
control character tables and port control word. 


Table 5-12. UNISCOPE 100/UNISCOPE 200/DCT 1000/UTS 400/UTS 4000 Control Cuitiéear Detect Table 
(Part 1 of 2) 


Meaning of Setting 


See Ci word 2 
See Cl word 3 
See Cl word 5 
See Cl word 6 
End input data (DLE sequence) 
See Cl word 1 
End input data (DLE sequence) 


See Cl word 0 


See Cl word 4 





* All other CD table settings are zero, implying data characters. 
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Table 5-12. UNISCOPE 100/UNISCOPE 200/DCT 1000/UTS 400/UTS 4000 Control Character Detect Table 





(Part 2 of 2) 


CD Table 
. Setting® 
(hexadecimal) 


End input data (DLE sequence) 


End input data (DLE sequence) 
End. input data (DLE sequence} 
See Cl word 2 
See Cl word 3 
See Cl word § 
See Ci word 6 
End input data (DLE sequence) 
See Ci word 1 
End input data (DLE sequence) 
See Ci word 0 
See Cl word 4 
End input data (DLE sequence) 
End input data (DLE sequence) 


End input data (OLE sequence) 


-* All. other CD table. settings are zero, implying data characters. _ 1 


Table 5~13. UNISCOPE 100/UNISCOPE 200/DCT 1000/UTS 400/UTS 4000 Control! Character interpretation Table 


through 
16 


Suppress character, suppress BCC accumulation for this character 


Start input data 


Start input data, start BCC, and suppress 
BCC accumulation for this character 


Start input data and start BCC 
Suppress character and end character 
Suppress character and end character 
Seat input data and start BCC 


Not used 


Not used 
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Table 5-14. UNISCOPE 100/UNISCOPE 200/DCT 1000/UTS 400/UTS 4000 Port Control Word 


Specific start character on input, 
four SYN characters on output 


One-unit interval stop element 
{asynchronous} 


Seven-bit character length (both 
synchronous and asynchronous) 


300 bps* 
1200 bps® = 
1800 bps* 
2400 bps°* 


Start character included in LRC 


ANSI standard (synchronous} 
parity function 


ANSI standard (asynchronous) 
.parity function 


Synchronous 
Asynchronous 





& * Asynchronous ine speed 


5.6. BSC REMOTE DEVICE HANDLER 


Tables 5-15 through 5-23 list the initialization parameters provided in the BSC remote 
device handler for the ane character tables and port control word. 


Table 5-15. BSC ASCII Msnacanaconkt Control Cora Detect Table (Part 1 of of 2) 


7 See Cl word 3 7 
See Cl word 3 
See Ci word 5 
See Cl word 5 
See Cl word 7 


See Cl word 2 


@ See Ci word 2 





See e word 1 


“All other CD table entries will be zero, implying data cebraciene: 
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Table 5-15. BSC ASCIl Nontransparent Control Character Detect Table (Part 2 of 2) 


CD Tabie : 
Setting* Meaning of Setting 
(hexadecimal) 
Start and end 
See C! word 0 
See Cl word 4 
Suppress character 
See Ci word 4 
See Cl word 6 
End input (DLE sequence) (ACK 0) 
End input (OLE sequence) (ACK 0) 
End input (DLE sequence) (ACK 1) 


End input (DLE sequence} (WACK) 





End input (OLE sequence) (RVI) 


*All other.CD table entries will be zero, implying data characters. 


Table 5-16. BSC ASCII Nontransparent Comtrol Character Interpretation Table 


through 
16 


- SYN character, suppress on input, no BCC 


DLE, start input 

Start character plus end character 
SOH, STX, start input, start BCC 
ETB, end character 

ETX, end character 

ITB, intermediate end character 


EOT, start input, end character 








5-10 
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Table 5-17. BSC ASCIl Nontransparent Port Control Word 





” Start character omitted from LRC 
BSC ASCII parity option 


Synchronous 
















See Cl word 4 
See Ci word 2 
" See Cl word 0 
See Ci word 7 
Start at end character 
End input (OLE sequence) (WACK) 
End input (DLE sequence) (ACK 0) - 
End input (OLE sequence) (ACK 1} 


End input (DLE sequence) (RVI) 





*Afil other CO table settings will be zero, implying data characters. 


5-11 
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Table 5-19. BSC EBCDIC Control Character Interpretation Table 


SYN character, suppress on input, no BCC 
DLE, start input 
ENQ, start input, end character 


SOH, STX, start input, start BCC, set transparent 
mode 


ETB, end character, clear transparent mode 
ETX, end character, clear transparent mode 
ITB, interrnediate end character 


EOT, start input, end character 


Specific start character on input, 
four SYNs on output 


Eight-bit character length . 


Start character omitted from CAC 
BSC CRC-16 





Synchronous 
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Table 5-21. BSC Transcode Control Character Detect Table 


Transcode 
Character Meaning of Setting 
(hexadecimal) 
See C) word 3 


See Cl word 3 


See Ci word 4 


See Cl word 6 

See Ci word 7 

See Ci word 1 

End input (OLE sequence) (ACK 0) 
End input (OLE sequence) (ACK 1) 
See Ci word 2 

See Cl word 5 

End input (DLE sequence) (RVI) 
See Ci word 0 


Start and end character 





Suppress character 


*Ail other CD table settings will be zero, implying data characters. 


Table 5-22. Bsc Transcode Control Character interpretation Table 


SYN character, suppress on input, no BCC 


DLE, start input 

ENQ, start input, end character 
SOH, STX., start input, start BCC 
ETB, end character 

ETX, end character 

ETB, intermediate end character 
EOT, start input, end character 


through 
15 Not used 
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Table 5-23. BSC Transcode Port Control Word OG eet net Ow er 


0,1 10 
2,3 01 
3 0 
4-7 1101 
4-6 001 


-. 5.7. AUTOMATIC DIALING 








Specific start character on input, 
four SYNs on output 





Six-bit character length 


Start character omitted from LRC 
BSC CRC-12 


Synchronous 





Control tables are not used for the autodial adapter. The port control word for the 
autodial adapter operation must have bit 6 of control byte 4 equal to 1. All other bits in 
the four control bytes must be set to O. 


When a DIAL command (05) is sent to the autodial adapter, the autodial adapter will 
check that the DATA LINE OCCUPIED signal is off and the POWER INDICATION signal is 
on prior to turning on the CALL REQUEST. signal. If these conditions are not met, the 
- CALL REQUEST signal is not turned on. In addition, if the DATA LINE OCCUPIED signal 
- i§ on and DATA SET STATUS is off, the autodial adapter will return UNIT CHECK - 
status and set the ABANDON CALL AND RETRY sense bit. lf the DATA LINE 
OCCUPIED signal and DATA.SET STATUS signal are both on when the DIAL command 
is received, the SLCA does not return UNIT CHECK status; however, this situation is 
avoided with proper software design (software should not issue a DIAL command when 
- the associated modem is in the data mode). UNIT CHECK and ABANDON CALL AND 
RETRY will also be generated if the POWER INDICATION signal from the ACU is off at 
the time the DIAL command is received by the autodial adapter. 





To avoid a potential race condition when aborting a call attempt (the CALL REQUEST 

signal is turned off before the DATA SET STATUS signal is turned on), the DATA 

TERMINAL READY signal to the associated modem must also be turned off when the 
CALL REQUEST signal is turned off. 


Dialing information from the System 80 buffer is presented to the autodial adapter by 
the SLCA one byte at a time. No CD tables are referenced for these bytes. 


The four most significant bits of the byte are stripped by the CMM, and the four least 
significant bits are interpreted by the autodial adapter as shown in Table 5-24. 


it should be noted that CCITT V.25 automatic calling equipment may require an 
end-of-number (EON) code following the dial digits. The EON option normally is not used 
with the Bell System 801 ACU. 








Weg /4O worm! Vojw ver lo 
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The format of the dial buffer should be as follows: toh dese 
@ Fist digit ! 


Second digit 


gets Last digit 
EON (if required by the ACU) 
End of dial (EOD) 
- Dummy character (requested by the SLCA but does not go to the autodial adapter) 


Dummy character (to prevent the byte count from going to zero) 





The last dummy character is required for the autodial adapter port to remain active so 
the ABANDON CALL AND RETRY signal or DATA .SET STATUS signal from the 
“automatic calling unit will be reported by the SLCA. When either of these status 
Ls ~ conditions is reported, software should issue an LA CLEAR command to reset the CALL 
PEGUES! signal. - aS tt, Te 8 ; 
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Table 5-24. Dialing information 


| opt | Autodial Adapter 
Digit 0 

Digit 1 

Digit 2 

Digit 3 

Digit 4 




























Digit 5 
Digit 6 
Digit 7 
Digit 8 
Digit 9 
Do not use 
End of Dial (EOD) 
End of Number (EON) 
Do not use 
Do not use 


Delay* 


*tf semt to the autodial adapter, the delay . 
‘digit will be discarded but will result in a 
pause of approximately 1.0 ~ 0.6 second 
‘in the dialing sequence. A number of delay 
digits may be loaded in. a dial buffer to 
effect time delays (for example, to wait for 
the second dial tone if dialing over a 


tieline). 
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Appendix A. Control Tables _ 
e 


re A.1. COMMUNICATIONS CONTROL PACKET a, 


This control packet is an activity request packet for the physical inteface. You must 
construct a packet of the following structure in your user program area and enter the 
specific. parameters you require before execution of each CCRCALL macroinstruction. 


Figure A-1 shows a functional field description and summary of the related DSECT 
symbolic labels. A detailed description of the control packet and usage is provided in 
Table A-1 and in the following text. The control packet is described in terms of the 
TN#PARP dummy control section, which may be obtained from the OS/3 system library 
by: 2. 5 ; 
e. TNHDSECT CPIOCP | 


Each label of this DSECT begins with the prefix TN#P; therefore, in the table, only the 
label suffixes are shown. 
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Byte .¢] 1 2 3 


hardware command code 
(TN=PCMMD) 


contro! flags RDH: line contro! table address 


logical Command function j 
(TN®PFUNC) i 


(TN=PFLGS) user program: line request fields (TN#PLCT) 


channel number SLCA number port number 
(TN=PCHNL) (TN#PPORT) (TN#PS80P) 


reserved for ICAM (TN#¥PBFST) 





reserved for ICAM (TN#PBCUR) 


ee eg tt eee J 





LEGEND: 


ey System-supplied pararneters 


Figure A~1. Communications Physical Input/Output Control Packet (CPIOCP) Functional Field Description 
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Table A-1. Control! Packet Detailed Field Deseription (Part 1 of 10) 


The IRL bit is set only by you. When 
set, you get an immediate return in- 
line after CPIOCS has acted upon 


on its line queues, it uses activity 
control's chain field for work 
fields: 

Byte 0 = bits 0-1 of TN#PFUNC 
bits 2-3 used to controi 
butters greater than 
1024 

Byte 1 = bits 2-7 of TN#PFUNC. 

Byte 2 = bits 0-6 of TNSPMUX 





CPIOCS sets TN#PRESV to 0 before 
returning CPIOCPs to you. You 
must set TN#PRESV to 0 in all 
chained CPIOCPs before executing 
CCRCALL. 


When chained CPIOCPs are 
scheduled back to you, only the 
completion address of the first 
CPIOCP in the chain is used. H you 
‘| set byte 1 to EEy, you will not be 
scheduled contro! when this 
CPIOCP function is complete. The 
CPIOCPs will be unchained normaliy 
and then dropped from all CCR 
queues, This facility is NOT 
recommended for normal user 
operations. 





Clear REQUEST TO SEND signai 
No line turnaround 


Primary logical status This field will be set to 0 by 
CPIOCS when CPIOCP is first 

tdie time status - line received. 

information not especially 

related to message 

completion. 
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Table A-1. Control Packet Detailed Field Description (Part 2 of 10) es 





Hardware error ~ do not retry. 

Program error 

Link level exception - line error 

but retry is indicated. 

Erroneous function/message 

completion. 

Function/message completion 

tion cage 


Detailed togical status This field will be set to 0 by 
CPIOCS when CPIOCP is first 
received. 








Device (SLCA not operational, unit 
exception) 


CPIOCP format or procedure Refer to Table A-3. When this error 
error is reported by user program interface 
code, even more detailed status is 
reported in TNPSEN2. 


Attach error 

Detach error 

Load program phase error 
User program line request fine 
error Requested line is already allocated. 





Maximum number of user Refer to 3.6. ICAM cannot process 
program task identities another user program task. 
exceeded 
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Table A-1. Control Packer Detailed Field Description (Part 3 of 10) 


completion 
Butfer completion 
notification 


Return of CPIOCPs due to 


Byte 0 = device status 
Byte 1 = channel status 


CCRU CPIOCP format error code 


An example is no hardware sense 
bits returned for a SENSE command. 


The interpretation of the value (bits) 
in this field is dependent on the value 
of TN#PRIM. 


See Table A-2. 


These fields will be set to 0 by 
CPIOCS when CPIOCP is received. 
When TN#PRIM = TN#PROGE, and 
TIN#PDETL = TNS#PFRMT, then 
TN#PSENZ will be set to the values 
in Table A-3 when an error has 
been detected by the user program 
interface code. If device errors 
occur, sense bytes 2 and 3 are 
reported here. See Table A~4. 
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= Table A~1. Control Packet Detailed Field Description (Part 4 of 10) 





Residual byte count for output, This field will be set to 0 by CPIOCS 
or input character count for input | when CPIOCP is first received. 
When the input character count is 
reported in more than one CPIOCP 
(buffer chaining) for a particular 
message, each CPIOCP contains 
the total accumulated count thus 
far. This field is not for immediate 
commands (commands that do not 
result in device or channel status). 


Hardware command code NOTE: 
When this field is not set to 0 by 
you, CPIOCS will not translate the 
logical command function in 
TN2PFUNC (bits 2-7) to obtain 
proper hardware command 
code. Whatever value was last 
here or whatever value .you set 
will be issued to the SLCA 





The CPIOCP at the head of any 
CPIOCS line queue, when this 

field is not 0, is decremented by 1 
each time CCRs timer services is 
notified that 1 second has elapsed. 
When this field decrements to 0, a 
HALT DEV command is issued, 

and the CPIOCPs are scheduled 
back to you with TN#PRIM = 
TN#PLLE and TN#PDETL = 
TN#PTIMD. H, however, the logical 
command function (TN#PFUNC, 
bits 2-7) was set to TN#PIDLT, a 
HALT DEV command is issued, 

but the CPIOCP is scheduled back 
to you with TN#PRIM = TN#PEND 
and TN#PDETL = TN#PEOM. 

The accuracy of this field can be off 
by minus 1 second, depending on 
when CCRs timer service is next 
notified that 1 second has elapsed. 











Wes 
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Table A-1. Control acres Detailed Field eeneee {Part 5 of 10) 


Start and end of message/function 


Bits 2-7 specify the logical 
Crest function 


Tips Wii wea 
by CCRs timer services, you must 
be careful to reset this field before 
reusing this CPIOCP for another 
CCRCALL. 


Both TN#PTIME and TN#PBLTH 
are used by the user program for 
Line Request. 


When TN#PFS is set to 1, it indicates 
that this CPIOCS is the first CPIOCP 
for @ particular message or function. 
When it is set to 0, it means that 
chained CPIOCPs are being used to 
output or input a message and this 
particular CPIOCP is not the first one. 
Refer to 3.1 for information regarding 
the setting of this bit for message 
chaining. 


When TN#PFL is set to 1, it indicates 
that this CPIOCP is the last CPIOCP 
for a particular message or function. 
The setting of this bit for the last 
CPIOCP of an output message is par- 
ticularly critical. When TN#PFL is 
set to 0, it means CPIOCP is being 
used in butter chaining and that it is 
not the last CPIOCP of the chain. When 
you know that a particular CPIOCP is 
the only one used to perform a func- 
tion, TNSPFS and TN#PFL should 
both be set (TNSPFSL). 


Refer to Table A-5S for a cross- 
referencing of the logical command 
function, the hardware command 
code, and the hardware command 
code as it is represented in 
TN#PCMMD. 





UP-9746 





SPERRY OS/3 


ICAM COMMUNICATIONS PHYSICAL INTERFACE (CPI) 


Table A-1. Control Packet Detailed Field Description (Part 6 of 10) 


Dial 
Send space (asynchronous only) 


Send mark (asynchronous only) 


Send sdle ; 

Enable data input 

Same as TN#+PED! 

New sync 

immediate look for sync 
Port turn off 


No Si0 instruction is issued. 

A CPIOCP for this function is 
issued only to receive notification 
of an interrupt when no message 
processing is in progress, such 
as the RING interrupt. Hf an 
interrupt other than unit 

check is received for a line with 
no CPIOCP active on the CPIOCS 
line queue, the interrupt will be 
ignored. Reter to 3.5 for automatic 
issuing of a SENSE command in 
response to unit check. 


Return all CPIOCPs currently on 
the CPIOCS line queue, marking 
the head CPIOCP with a status of 


TW#PRIM-= TN#PEND and 


TNSPDETL = TN#PGIVB. Then, ~ 
perform a HALT DEV command. 


This output function should be used 
instead of TN#PRTS for all output 
messages unless you know that sub- 
sequent output messages will 

follow with no intervening input. 
This function enables the SLCA fast 
turnaround logic which drops the | 
request-to-send load and prepares 
for input. 


ff either a CPIOCP or an SLCA 

time-out occurs for this function, 

the status returned is 

TN+PRIM = TN#PEND and 
=PDETL == TN#PEOM. 


This command disables interrupts 
and must be used with caution. 


No data transfer is processed. 
No immedizie status 


A-8 
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Table A-1. Control Packet Detailed Field Description (Part 7 of 10) Serene 





red 

Enable data set ready monitor 
Set full duplex 

LA test 

Modem test 

Line adapter turn off 

Enable data output for output/ 
output sequence of message 


Send idie and wait for CPIOCP 
time-out - not an immediate 
command. 


Load port contro! word 
(bytes 1-4) 

Load control bytes 2, 3, 4 
Load contro! bytes 3, 4 
Load control byte 4 

Load contro! character detect 
table 1 

Load contro! character detect 
table 2. 

Load contro! interpretation 
table 1. 

Read port contro! word 
Read control character detect 
table 1 

Read control character detect 
table 2 

Read contro! interpretation 
table 1 

NO-OP 


read random access memory 


Load memory address 





Load random access memory 


This output function does not clear 
request-to-send as does TN#PSEND. 


This send idle function does not 

result in an immediate command. 

Status is not returned to you 

until the hardware interrupts or 

until 2 CPIOCP time-out occurs. 

H a CPIOCP or an SLCA time-out 

occurs for this function, the status 

returned is TN#PRIM = TN3PEND 

and TN#PDETL = TN#PEOM. 7 
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el. S[EEE 
Alco 


Diagnostic modem test 

User program line release 

User program line request 

User program read fine link 

table 

User program network request 

User program network release 
X |CPIOCP chain address field 


- Suppress buffer completion 
interrupt scheduling 


Error schedule only 
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Refer to 26 
Refer to 2.3. 


Refer to 3.3. = 


Refer to 2.2. 
Refer to 2.7. 


Refer to 3.1 for a complete 
description of chaining and 
unchaining CPIOCPs to support 
data buffer chaining and message 
chaining. 


NOTE: | 
Do not chain a CPIOCP to my ey 
itself either directly or 

later in the chain. 





Whenever a buffer completion 
interrupt occurs, the CPIOCP 

for that butfer will be scheduled back 
to you unless this fiag is set. When 
this flag is set, the scheduling will 
be delayed. Refer to 3.1 for a state- 
ment about scheduling suppressed 
CPIOCPs. 


When this flag is set, the schedul- 
ing of the CPIOCP back to you will 
be delayed if it has a successful 
completion status (TN#PRIM = 
TN+PEND and TN#PDETL = 
TN#PEOM or TN#PBCI). 


NOTE: 
The last CPIOCP in a chain must 
not have this flag set. 
Refer to 3.1 for an explanation of 
how suppressed CPIOCPs are 
Scheduled back to you. Z oa 
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Table A-1. Comet hanes i Oeoeee Field Descipemn co 9 of 7 


BSC is now operating in 
transparent mode. 


Condition code The SiO condition code for the last 
command issued for this CPIOCP 
is saved here. 
00, = successful 
01, = unsuccesstul, status 
pending 
10, = busy 
1], = ilegal port (eg., 104 
or 134) or SLCA not operational. 


Multipurpose field: 
ROH fine control table address; or | The RDH line contro! table is 
where RDH saves line information. 
User program line request Refer to 2.3 for information about 
fields the user program line request 
Line request flag field 
TNSPROFG = TN#PLCT 
~ Request full-duplex queueing 
~ Request full-duplex line 
CA tables discipline 1D 
TNSPDSPL = TN#PLCT + 1 
~ User discipline 1D 


CA tables ID 
TN#PCAD = INHPLCT + 2 


Full word address TNS PLCTF = TNZEPFLGS + TNSPLCT 
Channel wba 

SLCA number 

Port number" 

X-21 contro! fiag 

X21 “a port 0 to 0 


X21 implicit chain 
lORBs 


A-11 
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Be Table A-1. Control Packet Detailed Field Desereuon rae: 1 10 of dQ pes 


“lz = Word/Bit im 





— - |- - 

ee 
a 
[2 fos fe || ef or tewt cae 


ae [Satelit 


The following paragraphs describe the control packet on a word and byte basis. 










— — ome 





= Word 1 — Priority and Activity Control (TN#PRTY and TN#PRESV) 


Byte O is used to designate an immediate return line. An IRL transfers control inline 

_ immediately following the CCRCALL macro; however, control will also be passed to 
your completion address as specified in word 2. You set this byte to regain control 
while ICAM -is performing input/output functions. Your program is disconnected 
from ICAM at this point until you issue a non-IRL macro or a CYIELD instruction. © 
(See example 1.) Bytes 1 through 3 are restricted to activity control usage and are | 
unusable by your program. 





Example 1: 
LBLPACKT DC XL4'80000000' IRL 


LBLPACKT DC =F '@! No IRL 

sw Word 2 — User Completion Address (TN#PFCPL) 
The user completion address, the label of an entry point in your program where 
status notification is to be scheduled, must be written as a full-word address 


constant as shown in example 2: 


Example 2: 


” 


DC ACCOMPADDR) Entry point for status notification 














Device status 
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Word 3 — User Flag Field and Activity Control Address . eS 
Byte 8 — User flag field (TN#PTNDX) 
TN#PTRTS 
Clear REQUEST TO SEND signal in output/output messages sequences. 
TN#PLIDL 
No line turnaround after input completion. 
Byte 9 — LOCAP address (TN#PLOCA) 
Used by activity control. 


Word 4 — Status Word (TN#PRIM, TN#PDETL, and TN#PSTAT) 


' Word 4 is initialized to zero by CPIOCS, since it is dynamically filled whenever user 


status notification is scheduled. Bytes O and 1 are not hardware-generated codes 
but software-generated logical codes to facilitate some degree of hardware 
independence. Bytes 2 and 3 are filled with the actual hardware-generated codes. 
Byte 2 is reserved for device status and byte 3 for channel status. See Table A-2. 


7 ee A~2. Standard Frocesenr, Hewes Status Byte Settings 


| Channa: status 


Attention ; , Unassigned 


Status modifier Incorrect length 
Control unit end Program check 
Busy Invalid address 
Channel end | Channel data check : 
Device end Interface control check 


Unit check . . Channel control check 


Unit exception Buffer terminate 


Remote device handiers primarily use the software-generated status half word, 
while diagnostic routines supplied by Sperry use the hardware status half word. 








SPERRY OS/3 


-UP-9746 © 
ICAM COMMUNICATIONS PHYSICAL INTERFACE (CPI) 





Table A-3. Control Packet Format Error Code Specifications 





Hexadecimal : 

Value in interpretation of Error Code 

TN#PSEN2° 
Error condition not detected by user program interface code** 
No entry in SLCA load table to release 
Received user RDH discipline ID instead of requested system RDH discipline ID 
Invalid channel and/or SLCA number 
lilegal channel vaiue 
Buffer length field greater than 1024t 
TN#PLINK not zero as required for this function 
legal buffer address for read LLT or read SLCA tables function 
CPIOCS line queue not empty before line release function 
liegal set of SLCA tables specified for line request 
CPIOCP chained to itself or TN#PRESV + 1 not zero when CPIOCP issued 


TN#PLCT has illegal address. 





Wiegal logical command function 
Buffer address pius length exceeds program boundary. 
Load SLCA control tables function for tables not assigned to you 


SLCA number above highest SLCA specified by system generation 


SLCA number below first SLCA specified by system generation 


Not used 
SLCA number not assigned to you 
Line request for secondary channel port before that of primary channel 


Line release for primary channel before secondary channel 





* When TN#PRIM = TN¥PROGE and TN#¥PDETL = TN#PFRMT, then TN#PSEN2 should be 
interpreted according to this table. 


** This error condition will occasionally ‘occur if two or more CPIOCPs are toggled (buffer 
chained) in order to input a message of unknown length. For example, when CPIOCP No. 1 
has been returned to you with TN#PRIM = TN#PEND and TN#PDETL = TN#PBCI, in order 
for you to process the data (if your program is interrupted by a message end condition for 
CPIOCP No. 2) you will reissue CPIOCP No. 1, not yet knowing the message is over. CPIOCP 
No. 1 will be scheduled back with this status because TN#PFUNC will not have -had bit O 
{TN#PFS) set. 
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= Word 5 — Sense Bytes and Output Residual Byte Count/Input Character Count 
@ (TN#PSENS and TN#PRBC) 


Word 5 is divided into two half-word fields. If user interface completion is not | 
successful, the first field contains a control packet format error code. If completion 
is successful, see Table A—4. 4 


Table A-—4 defines the mapping of the functional sense bytes to the primary and 
detailed status fields in word 4. 


__Table A-4._ Sense Bytes Settings for CPIOCP Word 5 


TN#PRIM TN#¥PDETL 
ARP Status ARP Status 
Primary Detail 


ee meee em el eam ane ee ete tee ee ee ee ee 







NOOO WN - © 


*- 


NOMA O 


1 


The second half word is used as a residual byte count (RBC) for output and an. 
accumulated character count for input. When control packets are chained, the count 
is transferred to the various chained packets and reflects the total characters 
received thus far. If a 3-packet chain of control packets, each specifying buffer 
length, was used to handle a 54-byte input message, the packets would be marked 
as follows: 


CPIOCP1 001416 (decimal 20) 

CPIOCP2 0028:6 (decimal 40) 

CPIOCP3 003616 (decimal 54) 
The output RBC is the difference between the length of the buffer and the number 
of characters transferred over the line. (If a user specifies a 40-byte buffer and the 


e@ end-of-message character is located at byte 32, an RBC count of 8 results.) This 
r word is initialized to zero by CPIOCS because it is dynamically filled by CPIOCS. 
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= Word 6 — Hardware Command Code and Buffer Address (TN#PCMMD and ~ 
TN#PBADR) 





Word 6 is divided into two fields: a 1-byte hardware command code field and a ~~~ 
3-byte buffer address field. (See example 3.) The hardware command can be a 
user-specified or [CAM-generated field. If you clear (zero) this field, CPIOCS looks at 
the logical function field of word 8 and translates the appropriate hardware 
command into this field. When the field is not zero, no translation is performed. 
Hardware independence is furthered by zeroing the field. (This can also effectively 
cause the second field to become a 4-byte address field.) Refer to Table A—5. 


It is strongly recommended that both the remote data handler and the user program 
always zero the hardware command code before issuing the CCRCALL. In this way, 
recoding and errors can be eliminated from user programs when ICAM is executed 
on new or different communications subsystems. 


The buffer address field contains the address where the data will reside for sending 

or receiving. The data must be in the output code expected by the remote terminal. 

The proper code (ASCII, Baudot, or transparent EBCDIC; must be used, as well as 

all message control characters. Input messages are delivered in the code sent by 
_ the remote terminal, and translation by your program is required. 





Example 3: 
: DC 8: XL1'@1" Physical command send data 
DC —. ALB COUTBUFF) Buffer address 
* (or) 
oc ACOUTBUFF ) 4-byte address in N leading zero 
* Cor)” 
oc X'ee! Zero physical command 


oc AL3CINBUFF) 3-byte input buffer address 


Table A-§. Cross-Reference of Logical Command Functions and Hardware Command Codes (Part 1 of 3) 


TNePFUNC TNePFUNC 


TN#PWAIT Wain for interrupt. 


+ TN#PIOFF immeciate port tumoff Clear active. 


TN#POTR Set data terminal ready. Set data terminal ready. 
Clear active. 


. TN#PSEND Enable data output (half- EDO with fast tumaround 
Guplex kine). clear of request to send 
Enable data output (full- EDO without fast turnaround 
duplex kine). clear of request to send 





TN#PDIAL Dual. Dial. 











a 
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Table A-5. 


TN#PFUNC 
(Bits 2-7) 
Hardware 

DSECT Label! 


TN#PFUNC 
(Bits 2-7) 
Hexadecimal 
Value 


TN#PLATO 


TN#PRTS 


TNePIOLT 


TN#PLB14 


TN#PLB24 


TN#PLB34 


TNePLB4 


TN#PLCD1 


TN#PLCD2 


TNAPLCIT 


sequence of messages. 


Send idie (not immediate). 


Load port contro! word 
(bytes 1-4) 


Load contro! bytes 2, 3, and 4. 
Load contro! bytes 3 and 4. 
Load contro! byte 4. 


Load control character 
detect table 1. 


Load control character 
detect table 2. 


Load control interpretation 
table 1. 


Cross-Reference of Logical Command Functions and Hardware Command Codes (Part 2 of 3} 


Line adapter test 
Modem test 

Tumoff 
Enable date output with 
no fast turnaround clear 
of REQUEST TO SEND. 
Send idie. 


Load control bytes 1, 2, 3. 
and 4. 


Losd control bytes 2, 3, and 4. 
Load control bytes 3 and 4. 
Load contro! byte 4. 


Load control character 
detect table 1. 


Load comtrol character 
detect table 2. 


Load contro! interpretation 
table 1. 





ee et ee 


eae 
( 
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Table A~S. Cross-Reference of Logical Command Functions and Hardware Command Codes (Part 3 of 3} 





TN#PFUNC TN#PFUNC 7 Hardware 
(Bits 2-7) (Bits 2-7) Logical Command Command 
Hardware Hexadecimal! Function Code in 

DSECT Label Value TN#PCMMD 


TN#PRPCW 


TN#PRCD1 























UP-9746 SFEARY Us/s A-19 


ICAM COMMUNICATIONS PHYSICAL INTERFACE (CPI) 


Word 7 — Time Allocation and Buffer Length (TN#PTIME and TN#PBLTH) 


Word 7 is composed of a half word of time allocation in seconds and a half word 
of buffer length, respectively. (See example 4.) The systems timer, in conjunction 
with CCR timer services, controls the passage of 1-second intervals. Time-outs 
present a primary status of line link exception. No timing out of the control packet 
function will be performed if the initial timer value is zero. A recommended 
minimum time allotment is 2 seconds, based on the accuracy of the timer and rapid 
interrupt notification. 


The maximum buffer length that CPIOCS supports without restrictions is 102410 
(40016). For configurations of CPIOCS which support physical user programs and 
transient ICAM, CPIOCS will support message buffer lengths of any size up to 
65,535.10 (FFFF.6) bytes with one restriction. If a buffer exceeds 1024 bytes, it 
must be for an entire message. (Buffers greater than 1024 cannot be chained 
together by the user to transfer a single message.) 


Refer to 3.2 for special use of the time and length fields for user program line 
request. 


Example 4: 
WORD? pc H'3! 3-second time allotment 
DC H'47' _ 47-byte buffer 
* (or) 
pc F'47! . No time, 47-byte buffer 
* Cor) 
oc H'@! Same as above 
oC H'47! 


Word 8 —- Logical Command Function and Chain Address Field (TN#PFUNC and 
TN#PLINK) | 


Word 8 comprises a 1-byte logical command function followed by a anne control 
packet chain address field. The least significant six bits of the logical command 
function field are used to obtain the hardware command code only if the hardware 
command field is zero. 


As shown in example 5, the labels rather than the actual values are used in the 
logical command function field. The use of the logical operator + (plus) allows the 
AND function to be performed on labels to effect multiple specifications. The labels 
are not subject to change, while the value could possibly change; therefore, the 
DSECT labels should be used as a general convention. 


When chained control packets are required, the 3-byte address constant format 
should be used as shown in word 6. 
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Example 5: 





SOFTFUNC DC YLICTN#PSEND + TNHPFSL) The line labeled SOFTFUNC causes 


| 

* " @ send-data command to be executed; | 
* it also states by logical operator + TN#PFSL 
* that this is the first and last CPIOCP. 
* (Thus a complete message-sized 

buffer is implied.) } 
CONTFUNC DC YL1CTNHPEDI) The line labeled CONTFUNC implies the 
* continuation of an input function. ; 
* i 
* 


ENDFUNC DC YLICTNHPSEND + TN#HPFL) The line labeled ENDFUNC says to end 
* an output sequence with the depletion 
* of the current buffer. 


= Word 9 — Flags and Special Tasks (TN#PFLGS and TN#¥PLCT) 


. Word 9 has a 1-byte operational flag field set by your program and a 3-byte field 
labeled TN#PLCT, which has four uses. 


The flag field has six major processing directives under control of user settings. 
- The labels used (DSECT) are shown as follows, with a description of their usage: 





TN#PESO 


Suppress notification of successful completion until a packet in a chained 
sequence is encountered without this bit setting or until an error occurs. The 
original intent of this setting was to take a complete polling sequence of 
output and input chained packets and delay the notification of your program 
until a response to a traffic poll has been received by the computer. This 
method eliminates notification of the remote device handlers whenever good 
status is presented. The completion address of the first packet is the place in 
your program where control is passed. When control is returned to you, the 
logical status (TN#PRIM and TN#PDETL) of the last contro! packet in the chain 
(or the control packet that had the error) overlays that of the head control 
packet of the chain. 


-» TN#PCIX 


Suppress the notification of buffer completion interrupts until a terminating 
device status is presented (complete message or error). 


TN#PTRNP 





Informs CPIOCS that binary synchronous communication is now using 
transparent mode. 
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The field labeled TN#PLCT is used differently, depending on the user. 


@ -— if the user is a remote device handler, it contains the address of the line 
contro! table. 


— If the user program is performing a line request, this field is used to assign 
access to the SLCA discipline ID and control character tables (2.3). 


= Word 10 — Channel! and Port Numbers (TN#PMUX) 


Byte O is for the channel number and byte 1 is for the SLCA number. A System 80 
Model 4 or 6 supports one to eight SLCAs. A System 80 Model 8 can support up 

- ° to 14 SLCAs with an attached input/output microprocessor (IOMP) or 28 SLCAs 
with a dual IOMP (14 full-duplex mode/28 half-duplex mode). 


Table A—-6 details how the channel and SLCA numbers can be assigned. The SLCA 
ID range for Model 8 is from O116 to OF:6, although the maximum assignable is 14 
SLCAs. 


Table A~6. Channel and SLCA ID Assignments — ees 
| Model CHANNEL (Byte 1) | SLCA ID (Byte 2) 
3-6 02 O8-OF 


8 (single 1OMP) |. 01~0F 





(dual |OMP) 


Byte 2 is for the port number. Port O is for special control; port: 1 is for output; 

- and port 2 is for input. The 2-way. alternate (half-dupiex) operation, therefore, 
assumes port 1 is for both output and input if the set-full-duplex command is not 
set. For full-duplex operation, you specify port 2 for input by issuing the © 
set-full-duplex command. 


Example 7 shows a typical coding for an SLCA without an IOMP. Example 8 shows a 
_ typical coding for SLCAs with a dual IOMP. 


Example 7: 
SLCA8 MVC TNHPMUX,=X'@208000¢' = For half-duplex operation 


SLCA8 MVC TN#HPMUX, =X'02080200' For full-duplex operation (input) 
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' Example 8: 

TOMP#1 
SLCO1 MVC TN#PMUX, =X'0D0102! Full duplex 
SLCO2 MVC TN#¥PMUX,=X'@D0202' Full duplex 
SLCO3 MVC TNHPMUX,=X'@D0301' Half duplex 
SLCO4 MVC TN#PMUX,=X'0D0401' Half dupiex 
SLC@5 MVC TNHPMUX,=X'@D@501' Half duplex 
SLCO14 MVC TNHPMUX,=X'@DOEO1! Half duplex 

IOMP#2 
SLC15 MVC TN#PMUX,=X'@FO102' Full duplex 
SLC16 MVC TNHPMUX,=X'@FO201! Half duplex 
SLC28 MVC -TNHPMUX,=X'@FOEO1' Half duplex: 


m Words 11 and 12 — Reserved 


= Words 13 and 14 — Sense bytes (TN#PS80S). This data is system-supplied. 


A.2. LINE LINK TABLE . 


The line link table is a configurable table based: on your physical network. It is 
composed of a 48-byte element for each SLCA defined at SYSGEN time. The first 
element is assigned to the lowest numbered SLCA defined, and the last element is 
assigned the highest numbered SLCA. Intervening SLCAs are assigned whether or not 
they are defined. 


Figure A-2 depicts the packets. It usage is illustrated by an English-language field 
description within the allocated fields. Table A-6 gives a detailed byte description of 
these fields, relating them to the applicable DSECT byte and bit labels. 
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’ DSECT TN#PLINE governs each 48-byte element of the line link table. This DSECT may 

© be obtained from the OS/3 user library by the proc call as shown in the following 
example: 

TNHDSECT LLT 


Each label has two parts: a prefix and a suffix. Table A—7 contains only the suffix; all 
labels are prefixed by TN#P. Detailed instructions are provided in 3.3 for the user 
program to read some portions of the line link table that are useful to you. 


-- 7 


Thirty-two bytes of 
information for icam 

use only. These bytes are 
not transferred by the 
read LLT function. 





E; System-supplied parameters 


Figure A~2. Line Link Table Functional Field Description 
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Table A-7. Line Link Table’ Detailed Field Descriptions (Part 1 of 2) 


CPIOCS line flags 
Data set ready off : 
Diagnostic trace enabled Set by interface code for line 
request 
Ful-duplex queueing Set by DUST for RDH 


Full-duplex line Set by interface code (line request) 


for user program 
Task control block address 


SLCA ID for dial adapter Set by SYSGEN and 
or its companion data SLCA + ICAM initialization 
Companion SLCA ID , Set by SYSGEN 

for this primary or secondary 

channel SLCA +t 


Line type 
Single line dial adapter SLCA 
Multiline dial adapter SLCA 
Primary channel SLCA — 
Secondary channel SLCA 
PIOST SLCA set by SYSGEN 

Device type 

 Polied DCT 500 flag 

“ASCH DCT 500/TTY Flag 
Automatic 500 or DCT 524 
UNISCOPE 100/DCT 1000 
DCT 2000 
9000 computer - 1004 mode 
9000 computer - 929 mode 
1004 
$200 
9300 
BSC terminal, TRANSCODE 
BSC CPU batch, TRANSCODE 
BSC CPU interactive, 

TRANSCODE 

BSC terminal, EBCDIC 
BSC CPU batch, EBCDIC 
BSC CPU interactive, EBCDIC 
BSC terminal, ASCII 
BSC CPU batch, ASCII 
BSC CPU interactive, ASCH 
1004 EMULATION line 
Series 1100 
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Table A-7. Line Link Table* Detailed Field Descriptions (Part 2 of 2) . 


Set by SYSGEN 


Autodialer associated with 

this SLCA 

Synchronous line 

Time speed (4 bits) 

~ Asynchronous value is 
identical to value 
specified in port 
control word 

- Synchronous value: 
B’0000' 
B'0001' 
B°0010° 
B°0011’ 
B°0100" 





°* The OSECT tabel of this table is TN#PLINE. 
* All labels have the prefix TN#P. 
+ ‘TN#PTYPE, subfield TN#PSDL or TN#¥PMDL indicates SLCA is for autodial adapter. 


tt TN#PSPED, subfield TN#PACU indicates SLCA is associated with an autodisier. TN#PTYPE, subfields TN#PPRIM and 
TN#PSEC indicate whether this port is a primary or secondary channel. ‘ 
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